消息中間件對比

消息隊列中間件

一、做用：應用解耦、彈性伸縮、冗餘存儲、流量削峯、異步通訊、數據同步

二、具體：

ActiveMQ ： Apache 出品的、採用 Java 語言編寫的徹底基於 JMS1.1 規範的面向消息的中間件。

RabbitMQ ：採用 Erlang 語言實現的 AMQP 協議的消息中間件，最初起源於金融系統，用於在分佈式系統中存儲轉發消息。

Kafka：起初是由 LinkedIn 公司採用 Scala 語言開發的一個分佈式、多分區、多副本且基於 zookeeper 協調的分佈式消息系統，現已捐獻給 Apache 基金會。它是一種高吞吐量的分佈式發佈訂閱消息系統，以可水平擴展和高吞吐率而被普遍使用。目前愈來愈多的開源分佈式處理系統如 Cloudera、Apache Storm、Spark、Flink 等都支持與 Kafka 集成。

RocketMQ ：阿里開源的消息中間件，目前已經捐獻個 Apache 基金會，它是由 Java 語言開發的，具有高吞吐量、高可用性、適合大規模分佈式系統應用等特色，經歷過雙 11 的洗禮，實力不容小覷。

ZeroMQ ：號稱史上最快的消息隊列，基於 C 語言開發。ZeroMQ 是一個消息處理隊列庫，可在多線程、多內核和主機之間彈性伸縮，雖然大多數時候咱們習慣將其納入消息隊列家族之中，可是其和前面的幾款有着本質的區別，ZeroMQ 自己就不是一個消息隊列服務器，更像是一組底層網絡通信庫，對原有的 Socket API 上加上一層封裝而已。

其餘：騰訊系的 PhxQueue、CMQ、CKafka，基於 Go 語言的 NSQ，甚至相似 Redis 的產品。

三、功能維度

優先級隊列，優先級高的消息具有優先被消費的特權，若是消費者的消費速度大於生產者的速度，而且消息中間件服務器（通常簡單的稱之爲 Broker）中沒有消息堆積，那麼對於發送的消息設置優先級也就沒有什麼實質性的意義了，由於生產者剛發送完一條消息就被消費者消費了，那麼就至關於 Broker 中至多隻有一條消息，對於單條消息來講優先級是沒有什麼意義的。

延遲隊列，當消息被髮送之後，並不想讓消費者馬上拿到消息，而是等待特定時間後，消費者才能拿到這個消息進行消費。通常分爲兩種：基於消息的延遲和基於隊列的延遲。基於消息的延遲是指爲每條消息設置不一樣的延遲時間，那麼每當隊列中有新消息進入的時候就會從新根據延遲時間排序，固然這也會對性能形成極大的影響。實際應用中大多采用基於隊列的延遲，設置不一樣延遲級別的隊列，好比 5s、10s、30s、1min、5mins、10mins 等，每一個隊列中消息的延遲時間都是相同的，這樣免去了延遲排序所要承受的性能之苦，經過必定的掃描策略（好比定時）便可投遞超時的消息。

死信隊列/回退隊列/重試隊列，消息第一次消費失敗入重試隊列 Q1，Q1 的從新投遞延遲爲 5s，在 5s 事後從新投遞該消息；若是消息再次消費失敗則入重試隊列 Q2，Q2 的從新投遞延遲爲 10s，在 10s 事後再次投遞該消息。以此類推，重試越屢次從新投遞的時間就越久，爲此須要設置一個上限，超過投遞次數就入死信隊列。重試隊列與延遲隊列有相同的地方，都是須要設置延遲級別，它們彼此的區別是：延遲隊列動做由內部觸發，重試隊列動做由外部消費端觸發；延遲隊列做用一次，而重試隊列的做用範圍會向後傳遞。

消費模式，分爲推（push）模式和拉（pull）模式。推模式是指由 Broker 主動推送消息至消費端，實時性較好，不過須要必定的流制機制來確保服務端推送過來的消息不會壓垮消費端。而拉模式是指消費端主動向 Broker 端請求拉取（通常是定時或者定量）消息，實時性較推模式差，可是能夠根據自身的處理能力而控制拉取的消息量。

廣播消費，通常有兩種傳遞模式：點對點（P2P，Point-to-Point）模式和發佈 / 訂閱（Pub/Sub）模式。對於點對點的模式而言，消息被消費之後，隊列中不會再存儲，因此消息消費者不可能消費到已經被消費的消息。雖然隊列能夠支持多個消費者，可是一條消息只會被一個消費者消費。發佈訂閱模式定義瞭如何向一個內容節點發布和訂閱消息，這個內容節點稱爲主題（topic），主題能夠認爲是消息傳遞的中介，消息發佈者將消息發佈到某個主題，而消息訂閱者則從主題中訂閱消息。主題使得消息的訂閱者與消息的發佈者互相保持獨立，不須要進行接觸便可保證消息的傳遞，發佈 / 訂閱模式在消息的一對多廣播時採用。RabbitMQ 是一種典型的點對點模式，而 Kafka 是一種典型的發佈訂閱模式。可是 RabbitMQ 中能夠經過設置交換器類型來實現發佈訂閱模式而達到廣播消費的效果，Kafka 中也能以點對點的形式消費，你徹底能夠把其消費組（consumer group）的概念當作是隊列的概念。不過對比來講，Kafka 中由於有了消息回溯功能的存在，對於廣播消費的力度支持比 RabbitMQ 的要強。

消息回溯，……