01 redis發布訂閱和mq區別(redis和zeromq怎么選擇)

redis與rabbitmq做消息隊列的區別

消息隊列（Message Queue）是一種應用間的通信方式，消息發送后可以立即返回，由消息系統來確保消息的可靠傳遞。消息發布者只管把消息發布到 MQ 中而不用管誰來取，消息使用者只管從 MQ 中取消息而不管是誰發布的。這樣發布者和使用者都不用知道對方的存在。

redis

RabbitMQ

可靠性

rabbitmq：具有消息消費確認機制，如果發布一條消息，還沒有消費者消費該隊列，那么這條消息將一直存放在隊列中，直到有消費者消費了該條消息，以此可以保證消息的可靠消費，那么rabbitmq的消息是如何存儲的呢？（后續更新）；

實時性

redis:實時性高，redis作為高效的緩存服務器，所有數據都存在內存中，所以它具有更高的實時性

消費者負載均衡：

rabbitmq隊列可以被多個消費者同時監控消費，但是每一條消息只能被消費一次，由于rabbitmq的消費確認機制，因此它能夠根據消費者的消費能力而調整它的負載；

持久性

redis：redis的持久化是針對于整個redis緩存的內容，它有RDB和AOF兩種持久化方式（redis持久化方式，后續更新），可以將整個redis實例持久化到磁盤，以此來做數據備份，防止異常情況下導致數據丟失。

rabbitmq：隊列，每條消息都可以選擇性持久化，持久化粒度更小，更靈活；

隊列監控

rabbitmq實現了后臺監控平臺，可以在該平臺上看到所有創建的隊列的詳細情況，良好的后臺管理平臺可以方面我們更好的使用；

redis沒有所謂的監控平臺。

總結

redis：輕量級，低延遲，高并發，低可靠性；

rabbitmq：重量級，高可靠，異步，不保證實時；

RabbitMQ與redis的區別是什么呢？

首先說RabbitMQ，RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業級的開發。同時實現了Broker構架，這意味著消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

其次是Redis，Redis是一個基于Key-Value對的NoSQL數據庫，開發維護很活躍。雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高于RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

3.3ZeroMQ

ZeroMQ號稱最快的消息隊列系統，尤其針對大吞吐量的需求場景。ZeroMQ能夠實現RabbitMQ不擅長的高級/復雜的隊列，但是開發人員需要自己組合多種技術框架，技術上的復雜度是對這MQ能夠應用成功的挑戰。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務器或中間件，因為你的應用程序將扮演這個服務器角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應用程序之間發送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數據將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認使用ZeroMQ作為數據流的傳輸（Storm從0.9版本開始同時支持ZeroMQ和Netty作為傳輸模塊）。

3.4ActiveMQ

ActiveMQ是Apache下的一個子項目。 類似于ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現高級應用場景。

3.5Kafka/Jafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發布/訂閱消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分布式系統，Broker、Procer、Consumer都原生自動支持分布式，自動實現負載均衡；支持Hadoop數據并行加載，對于像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制統一了在線和離線的消息處理。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分布式系統。

上圖中一個topic配置了3個partition。Partition1有兩個offset：0和1。Partition2有4個offset。Partition3有1個offset。副本的id和副本所在的機器的id恰好相同。

如果一個topic的副本數為3，那么Kafka將在集群中為每個partition創建3個相同的副本。集群中的每個broker存儲一個或多個partition。多個procer和買粉絲nsumer可同時生產和消費數據。

RabbitMQ與redis的區別是什么呢?

1、我們介紹了RabbitMQ，Kafka和Redis的一些特征。這三種動物都是它們的類別，但是如上所述，它們的運行方式大不相同。這是我們建議正確的消息代理根據不同用例使用的建議。

2、redis消息推送（基于分布式pub/sub）多用于實時性較高的消息推送，并不保證可靠。其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。

3、測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。

4、消息隊列網絡是能夠相互間來回發送消息的任何一組計算機。網絡中的不同計算機在確保消息順利處理的過程中扮演不同的角色。它們中有些提供路由信息以確定如何發送消息，有些保存整個網絡的重要信息，而有些只是發送和接收消息。

5、redis只是提供一個高性能的、原子操作內存鍵值對，具有高速訪問能力，可用做消息隊列的存儲，但是不具備消息隊列的任何功能和邏輯，要作為消息隊列來實現的話，功能和邏輯要通過上層應用自己實現。我們以RabbitMQ為例介紹。

redis也可以實現隊列，為什么還要用rabitmq或者kafka

拋開業務場景談這些組件的選擇就是耍流氓。 負載不大，可靠性要求不高，沒有擴容需求的情況下自然都一樣，甚至就像之前說的，不用redis，就寫文件都行，往某個文件夾里寫個文件=>入隊，拿出來刪掉=>出隊

至于ack啊，分布式啊，抗壓啊等等各種問題，redis基本沒有現成解決方案，有的可以自己變通解決，有的就是解決不了，所以才會有各種各樣的專業隊列組件，有的注重速度，有的注重分布式，有的注重可靠性，他們都會試圖解決redis解決不了的一些問題。就好像你磁盤寫文件當key-value用，IO的速度自然成為瓶頸，負載能力上不去，所以才會有專業的redis來做內存的kv

redis和zeromq怎么選擇

在我的整個職業生涯里我都在使用C++，而且現在C++依然是我做大多數項目時的首選編程語言

自然的，當我從2007年開始做ZeroMQ(ZeroMQ項目主頁)時，我選擇用C++來實現

主要的原因有以下幾點：1

包含數據結構和算法的庫（STL）已經成為這個語言的一部分了

如果用C，我將要么依賴第三方庫要么不得不自己手動寫一些自1970年來就早已存在的基礎算法

2

C++語言本身在編碼風格的一致性上起到了一些強制作用

比如，有了隱式的this指針參數，這就不允許通過各種不同的方式將指向對象的指針做轉換，而那種做法在C項目中常常見到（通過各種類型轉換）

同樣的還有可以顯式的將成員變量定義為私有的，以及許多其他的語言特性

3

這個觀點基本上是前一個的子集，但值得我在這里顯式的指出：用C語言實現虛函數機制比較復雜，而且對于每個類來說會有些許的不同，這使得對代碼的理解和維護都會成為痛苦之源

Kafka，Mq和Redis作為消息隊列使用

kafka是個日志處理緩沖組件，在大數據信息處理中使用。和傳統的消息隊列相比較簡化了隊列結構和功能，以流形式處理存儲（持久化）消息（主要是日志）。日志數據量巨大，處理組件一般會處理不過來，所以作為緩沖層的kafka，支持巨大吞吐量。為了防止信息丟失，其消息被調用后不直接丟棄，要多存儲一段時間，等過期時間過了才丟棄。這是mq和redis不能具備的。主要特點如下:巨型存儲量: 支持TB甚至PB級別數據。高吞吐，高IO：一般配置的服務器能實現單機每秒100K以上消息的傳輸。消息分區，分布式消費：能保消息順序傳輸。 支持離線數據處理和實時數據處理。Scale out：支持在線水平擴展，以支持更大數據處理量

redis只是提供一個高性能的、原子操作內存鍵值對，具有高速訪問能力，可用做消息隊列的存儲，但是不具備消息隊列的任何功能和邏輯，要作為消息隊列來實現的話，功能和邏輯要通過上層應用自己實現。

我們以RabbitMQ為例介紹。它是用Erlang語言開發的開源的消息隊列，支持多種協議，包括AMQP，XMPP, SMTP, STOMP。適合于企業級的開發。

MQ支持Broker構架，消息發送給客戶端時需要在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

還有ActiveMq，ZeroMq等。功能基本上大同小異。并發吞吐TPS比較，ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。

原文：

很赞哦!（45）