一、什么是消息隊列（MQ）
MessageQueue 是一個廣泛應用在互聯網項目中且非常重要的技術， MessageQueue 通常被用來解決在高並發壓力下類似於流量削峰、服務解耦、消息通訊、最終消息一致性等這樣的問題。
二、什么場景下使用MQ呢？
MQ 可應用在多個領域，包括異步通信解耦、企業解決方案、金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通信、手游、視頻、物聯網、車聯網等。
從應用功能上來講。例如：
- 日志監控，作為重要日志的監控通信管道，將應用日志監控對系統性能影響降到最低。
- 消息推送，為社交應用和物聯網應用提供點對點推送，一對多廣播式推送的能力。
- 金融報文，發送金融報文，實現金融准實時的報文傳輸，可靠安全。
- 電信信令，將電信信令封裝成消息，傳遞到各個控制終端，實現准實時控制和信息傳遞。
從功能角度考慮：
- MQ 在實際應用中常用的使用場景主要有異步處理，應用解耦，流量削鋒和消息通訊四個場景
2.1 異步處理
場景說明：用戶注冊后，需要發注冊郵件和注冊短信。傳統的做法有兩種：
1.正常串行的方式
- 注冊信息寫入數據庫
- 發送注冊郵件
- 發送注冊短信
總共耗時150ms
2.並行方式（開啟異步線程）
- 注冊信息寫入數據庫
- 注冊郵件+短信
總共耗時100ms
假設三個業務節點每個使用 50 毫秒鍾，不考慮網絡等其他開銷，則串行方式的時間是 150 毫秒，並行的時間可能是 100 毫秒。 因為 CPU 在單位時間內處理的請求數是一定的，假設 CPU1 秒內吞吐量是 100 次。則串行方式 1 秒內 CPU 可處理的請求量是 7 次（1000/150）。並行方式處理的請求量是 10 次（1000/100）
小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？
答：引入消息隊列，將不是必須的業務邏輯，異步處理，改造后的架構如下：
按照以上約定，用戶的響應時間相當於是注冊信息寫入數據庫的時間，也就是 50 毫秒。注冊郵件，發送短信寫入消息隊列后，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是 50 毫秒。因此架構改變后，系統的吞吐量提高到每秒 20 QPS。比串行提高了 3 倍，比並行提高了兩倍。而且主流消息隊列都支持集群，也可以解決處理慢的情況。
當然了，也不光注冊這個場景，還有上傳文件啊，解析Excel啊，都可以考慮引入隊列，然后搞一個傳輸中心就可以了。
2.2 應用解耦
場景說明：用戶下單后，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口。如下圖：
傳統模式的缺點：假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗，訂單系統與庫存系統耦合
如何解決以上問題呢？引入應用消息隊列后的方案，如下圖：
訂單系統：用戶下單后，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功
庫存系統：訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作
假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單后，訂單系統寫入消息隊列就不再關心其他的后續操作了。實現訂單系統與庫存系統的應用解耦
2.3 流量削峰
流量削鋒也是消息隊列中的常用場景，一般在秒殺或搶夠活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，應用系統配置承載不了這股瞬間流量，導致系統直接掛掉，即傳說中的“宕機”現象。為解決這個問題，我們會將那股巨大的流量拒在系統的上層，即將其轉移至 MQ 而不直接涌入我們的接口，此時MQ起到了緩沖作用。
2.4 日志處理
日志處理是指將消息隊列用在日志處理中，比如 Kafka 的應用，解決大量日志傳輸的問題。架構簡化如下
-
日志采集客戶端，負責日志數據采集，定時寫入kafka隊列
-
kafka消息隊列，負責日志數據的接收，儲存和轉發
-
日志處理應用：訂閱並消費kafka數據
-
常用的日志收集架構有：
-
ELK/EFK
三、MQ產品對比
目前主流的MQ主要有：
- RabbitMQ
- RocketMQ
- kafka
- Activemq
3.1 MQ對比
|
**MQ**
|
**描述**
|
|
RabbitMQ
|
erLang開發（高並發語音），對消息堆積的支持不算太好，當大量消息積壓的時候，會導致Rabbit性能下降。每秒鍾可以處理幾萬到幾十萬條消息。
|
|
RocketMQ
|
java開發，面向互聯網集群化功能豐富，對在線業務的響應時延做了很多的優化，大多數情況。而且由於是java開發，如果想進行定制化擴展也比較方便
|
|
Kafka
|
Scala開發，面向日志功能豐富，性能最高。當你的業務場景中，每秒鍾消息數量沒有那么多的時候，kafka的時延反而會比較高，所以，Kafka不太適合在線業務場景。
|
|
Activemq
|
java開發，簡單，穩定，性能不如前面三個。小型系統用也ok，但是不推薦。
|
3.2 主流MQ的優缺點
| RabbitMQ | RocketMQ | Kafka | Activemq | |
| 協議 | AMQP | AMQP | 自行設計 | AMQP |
| 跨語言 | 支持 | 支持 | 支持 | 支持 |
| 優點 | 單機吞吐量： 萬級 健壯、穩定、醫用、跨平台、支持多種語言； 功能支持： MQ功能完備 高擴展性： 支持事務 | 單機吞吐量：十萬級 可用性： 非常高，分布式 架構： 消息可靠性高 功能支持：MQ功能完備 高擴展性：支持事務 | 單機吞吐量：百萬級 可用性：分布式的非常高 依賴ZK可動態擴展節點高性能高吞吐，消息可指定追溯 | 單機吞吐量：萬級 可用性：非常高 功能支持： MQ功能完備 高擴展性 |
| 缺點 | Elang語言難度大，很難擴展,研發人員較少 | 目前只支持java及c++； | 嚴格的順序機制，不支持消息優先級，不支持標准協議 | 項目比較陳舊，官方社區在5.X之后對其維護越來越少 |
| 綜合評價 | 適用於穩定性要求優先的企業級應用 | 阿里系，國內互聯網公司使用居多 | 在日志和大數據方向使用較多 | 小型系統比較適用，但是因為維護越來越少，建議不用 |
中小型軟件公司，建議選 RabbitMQ，一方面，erlang 語言天生具備高並發的特性，而且他的管理界面用起來十分方便。正所謂，成也蕭何，敗也蕭何！他的弊端也在這里，雖然RabbitMQ 是開源的，然而國內有幾個能定制化開發 erlang 的程序員呢？所幸，RabbitMQ的社區十分活躍，可以解決開發過程中遇到的 bug，這點對於中小型公司來說十分重要。不考慮 rocketmq 和 kafka 的原因是，一方面中小型軟件公司不如互聯網公司，數據量沒那么大，選消息中間件，應首選功能比較完備的，所以 kafka 排除。可以考慮阿里的 rocketmq.
大型軟件公司，根據具體使用在 rocketMq 和 kafka 之間二選一。一方面，大型軟件公司，具備足夠的資金搭建分布式環境，也具備足夠大的數據量。針對 rocketMQ,大型軟件公司也可以抽出人手對 rocketMQ 進行定制化開發，畢竟國內有能力改 JAVA 源碼的人，還是相當多的。至於 kafka，根據業務場景選擇，如果有日志采集功能，肯定是首選 kafka 了。具體該選哪個，看使用場景。
我們在進行中間件選型時，一般都是通過下面幾點來進行產品選型的：
1）性能
2）功能支持程度
3）開發語言(團隊中是否有成員熟悉此中間件的開發語言，市場上此種語言的開發人員是否好招)
4）有多少公司已經在生產環境上實際使用過，使用的效果如何
5）社區的支持力度如何
6）中間件的學習程度是否簡單、文檔是否詳盡
7）穩定性
8）集群功能是否完備
如果從以上 8 點來選型一個消息隊列，作為一名熟悉 java 的程序員，當遇到重新選擇消息隊列的場景時，我會毫不猶豫的選型 rocketmq，除了監控管理功能不友好外，從其它方面來說，它真的是一款非常優秀的消息隊列中間件。而且如果你的項目是用java編寫的話，使用rocketmq在排錯以及優化上，都可以自行進行定制。
作者：塔哥哥要學習
鏈接：https://juejin.cn/post/6896744901665521677
來源：掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。