消息隊列 ActiveMQ 、RocketMQ 、RabbitMQ 和 Kafka 如何選擇？

本文轉載自查看原文 2019-11-06 10:56 350

「預計閱讀 6 分鍾」

旁白：這是一篇拖更了N久的文章...0.0（看不見我~）

往期回顧

前端框架 jQuery 和 Vue 如何選擇？

安全框架 Shiro 和 Spring Security 如何選擇？

正文

消息隊列（MQ）

在百度百科中，消息隊列（MQ）是這么解釋的：“消息隊列”是在消息的傳輸過程中保存消息的容器（可存可取）。

它是分布式系統中重要的組件，使用消息隊列主要是為了通過異步處理提高系統性能和削峰和降低系統耦合性。

異步處理：多應用對消息隊列中同一消息進行處理，應用間並發處理消息，相比較串行處理，減少處理時間；
應用耦合：多應用通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失敗；
限流消峰：廣泛應用於秒查或搶購活動中，避免某一刻流量過導致應用系統掛掉的情況；

目前使用較多的消息隊列有 ActiveMQ 、RocketMQ 、RabbitMQ 和 Kafka 等。

消息隊列的兩種模式

消息隊列包括兩種模式：點對點模式和發布/訂閱模式。

1）點對點模式

點對點模式下包括三個角色：

消息隊列
發送者 (生產者)
接收者（消費者）

消息發送者生產消息發送到queue中，然后消息接收者從queue中取出並且消費消息。消息被消費以后，queue中不再有存儲，所以消息接收者不可能消費到已經被消費的消息。

點對點模式特點：

每個消息只有一個接收者（Consumer）(即一旦被消費，消息就不再在消息隊列中)；
發送者和接收者間沒有依賴性，發送者發送消息之后，不管有沒有接收者在運行，都不會影響到發送者下次發送消息；
接收者在成功接收消息之后需向隊列應答成功，以便消息隊列刪除當前接收的消息；

2）發布/訂閱模式

發布/訂閱模式下包括三個角色：

角色主題（Topic）
發布者(Publisher)
訂閱者(Subscriber)

發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

發布/訂閱模式特點：

每個消息可以有多個訂閱者；
發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之后，才能消費發布者的消息。
為了消費消息，訂閱者需要提前訂閱該角色主題，並保持在線運行；

異步處理

具體場景：用戶為了使用某個應用，進行注冊，系統需要發送注冊郵件和注冊短信。

對於該流程有兩種處理方式：並行和串行。

1）串行處理：寫入注冊信息后，先發送注冊郵件，再發送注冊短信。

這種方式下，需要等發送短信處理完成后才完成注冊。

2）並行處理：寫入注冊信息后，同時處理發郵件和發短信。

這種方式下，需要等發送短信和發送郵件處理完成后才完成注冊。

假設上面三個子系統處理耗時均為：50ms，且不考慮網絡延遲，系統卡頓等因素，則總的處理時間為：

串行：50ms + 50ms + 50 ms = 150ms

並行：50ms + 50ms = 100ms

使用消息隊列結果將如何呢？

若使用消息隊列，寫入完注冊信息后，再將信息寫入消息隊列就能直接返回成功給客戶端了，然后注冊完成。

現在總的響應時間依賴於寫入消息隊列的時間，而寫入消息隊列的時間是很快的，基本可以忽略不計。因此總的處理時間相比串行提高了 2 倍，相比並行提高了 1 倍。

應用解耦

具體場景：A 系統每次產生數據時，都要將數據發給 BC 兩個系統（通過接口調用）。這個時候新增了一個 D 系統，如下圖：

在這個場景中，A 系統和其他幾個系統亂七八糟的耦合在一起，當 A 系統中產生一條數據時，需要將數據發給各個系統。

每次項目中新增了系統，A 系統都需要修改代碼，還要時刻擔心那個系統掛掉了，信息沒發送過去要不要重發，那個系統又不要該數據了，這時求 A 系統負責人的心理陰影...

如果使用 MQ，A 系統產生一條數據后，只需要插入到 MQ 里面去，那個系統需要就去 MQ 里消費。如果新增了一個系統，那么訂閱 MQ 的消息即可；同理那個系統不再需要該數據，那么只要取消訂閱就行了。

通過一個 MQ， Pub/Sub 發布訂閱消息模型，A 系統就跟其他系統實現解耦了。

限流削峰

具體場景：某電商網站開展秒殺活動，一般由於瞬間訪問暴增，服務器收到請求過大，可能出現無法處理請求或崩潰的情況。

加入消息隊列后，系統就可以從消息隊列中讀取數據，相當於做了一次緩沖，超出系統處理之外的請求會積壓在消息隊列中，等高峰期已過，就會快速將積壓在隊列中的數據處理完。

消息隊列有什么優缺點

優點上面已經說了，就是在特殊場景下有其對應的好處，解耦、異步、削峰。

缺點有以下幾個：

系統可用性降低

系統引入的外部依賴越多，越容易掛掉。本來你就是 A 系統調用 BCD 三個系統的接口就好了，人 ABCD 四個系統好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整，MQ 一掛，整套系統崩潰的，你不就完了？如何保證消息隊列的高可用，可以點擊這里查看。
系統復雜度提高

硬生生加個 MQ 進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。
一致性問題

A 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。

所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，做好之后，系統復雜度提升了一個數量級，也許是復雜了 10 倍。但是關鍵時刻，用，還是得用的。

RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

這里列舉了上述四種消息隊列的差異對比（圖片來源：https://www.cnblogs.com/javalyy/p/8856731.html）：