RocketMQ基礎認知系列1一典型訊息中介軟體對比分析

中介軟體對比

ZeroMQ 

一種基於訊息佇列的多執行緒網路庫，其對套接字型別、連線處理、幀、甚至路由的底層細節進行抽象，提供跨越多種傳輸協議的套接字。ZeroMQ是網路通訊中新的一層，介於應用層和傳輸層之間（按照TCP/IP劃分），其是一個可伸縮層，可並行執行，分散在分散式系統間。

特點：擴充套件性好，開發比較靈活，採用C語言實現，實際上他只是一個socket庫的重新封裝，如果我們做為訊息佇列使用，需要開發大量的程式碼。

官網：http://zeromq.org/ 參考：https://blog.csdn.net/w174504744/article/details/73187697

RabbitMQ

一個由erlang開發的AMQP(Advanved Message Queue)的開源實現。

特點：具備erlang語言本身的併發優勢，效能較好，但是不利於做二次開發和維護

官網：http://www.rabbitmq.com/ 參考：https://blog.csdn.net/whoamiyang/article/details/54954780

ActiveMQ

Apache所提供的一個開源的訊息系統，完全採用Java來實現，因此，它能很好地支援J2EE提出的JMS（Java Message Service,即Java訊息服務）規範。JMS是一組Java應用程式介面，它提供訊息的建立、傳送、讀取等一系列服務。JMS提供了一組公共應用程式介面和響應的語法，類似於Java資料庫的統一訪問介面JDBC,它是一種與廠商無關的API，使得Java程式能夠與不同廠商的訊息元件很好地進行通訊。

特點：悠久的開源專案，已經在很多產品中得到應用，實現了JMS1.1規範，可以和spring-jms輕鬆融合，實現了多種協議，不夠輕巧（原始碼比RocketMQ多），支援持久化到資料庫，對佇列數較多的情況支援不好，不過我們的專案中並不會建很多的佇列.

官網：http://activemq.apache.org/  參考：https://www.cnblogs.com/jaycekon/p/6225058.html

Redis

個基於記憶體的K-V資料庫，其提供了訊息訂閱的服務，可以當作MQ來使用，目前應用案例較少，且不方便擴充套件。

特點：更多的用於快取，作為訊息佇列使用的場景較少。

官網：https://redis.io/

kafka

最初由Linkedin公司開發，是一個分散式、支援分割槽的（partition）、多副本的（replica），基於zookeeper協調的分散式訊息系統，它的最大的特性就是可以實時的處理大量資料以滿足各種需求場景：比如基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎，web/nginx日誌、訪問日誌，訊息服務等等，用scala語言編寫，Linkedin於2010年貢獻給了Apache基金會併成為頂級開源專案。

特點：基於Pull的模式來處理訊息消費，追求高吞吐量，一開始的目的是用於日誌收集和傳輸，0.8開始支援複製，不支援事務，適合產生大量資料的網際網路服務的資料收集業務。

優點：
可擴充套件。Kafka叢集可以透明的擴充套件，增加新的伺服器進叢集。
高效能。Kafka效能遠超過傳統的ActiveMQ、RabbitMQ等，Kafka支援Batch操作。
容錯性。Kafka每個Partition資料會複製到幾臺伺服器，當某個Broker失效時，Zookeeper將通知生產者和消費者從而使用其他的Broker。
缺點：
重複訊息。Kafka保證每條訊息至少送達一次，雖然機率很小，但一條訊息可能被送達多次。
訊息亂序。Kafka某一個固定的Partition內部的訊息是保證有序的，如果一個Topic有多個Partition，partition之間的訊息送達不保證有序。
複雜性。Kafka需要Zookeeper的支援，Topic一般需要人工建立，部署和維護比一般MQ成本更高。

官網：http://kafka.apache.org/ 參考：https://blog.csdn.net/ychenfeng/article/details/74980531

RocketMQ

阿里巴巴的MQ中介軟體，在其多個產品下使用，並能夠撐住雙十一的大流量，他並沒有實現JMS規範，使用起來很簡單。部署由一個 命名服務（nameserver）和一個代理（broker）組成，nameserver和broker以及producer都支援叢集，佇列的容量受機器硬碟的限制，佇列滿後可以支援持久化到硬碟（也可以自己適配程式碼，將其持久化到NOSQL資料庫中），佇列滿後會影響吞吐量，可以採用主備來保證穩定性，支援回溯消費，可以在broker端進行訊息過濾.

針對訊息中介軟體的選擇可以從以下方面進行考慮：(主要對比ActiveMQ和RocketMQ)
     優先順序：我們的專案對此需求不是特別明顯，RocketMQ需要新建一個特殊佇列來接收優先順序高的佇列，無法實現從0-65535這種細粒度的控制，ActiveMQ可以精細控制
     順序：我們的訊息匯流排中的訊息應該都是無狀態的，所以對訊息的處理順序沒有嚴格的要求，如果有特殊要求的話可以在業務層進行控制，activeMQ無法保證嚴格的順序，RocketMQ可以保證嚴格的消費順序
    持久化：都支援
   穩定性：RoketMQ在穩定性上可能更值得信賴，支援多種叢集方案，畢竟已經撐過幾個雙十一
   訊息過濾：ActiveMQ僅支援在客戶端消費的時候進行判斷是否是自己需要的訊息，RocketMQ可在broker端進行過濾，對於我們的訊息匯流排，這裡可以節省大量的網路傳輸是否會有訊息重發造成的重複消費：RocketMQ可以保證，ActiveMQ無法保證
   回溯消費：即重新將某一個時刻之前的訊息重新消費一遍，我們對於這種需求應該很少，RocketMQ支援，ActiveMQ不支援（RocketMQ的佇列是持久化到硬碟的，定期進行清除
          事務：都支援
  定時消費：RocketMQ支援
   訊息堆積：就是當快取訊息的記憶體滿了之後的解決方案，一種是丟棄策略，這種不不會影響吞吐量，還有一種就是將訊息持久化到磁碟，這種會影響吞吐量，在評估影響程度上，RocketMQ的成績稍微好一點

  客戶端不線上：RocketMQ可以在客戶端上線後繼續將未消費的訊息推送到客戶端

圖示說明[引用]