消息隊列作為服務(wù)/應(yīng)用之間的通信中間件，可以起到業(yè)務(wù)耦合、廣播消息、保證最終一致性以及錯峰流控（克服短板瓶頸）等作用。本文不打算詳細(xì)深入講解消息隊列，而是體系化的梳理消息隊列可能涉及的技術(shù)點，起到提綱挈領(lǐng)的作用，構(gòu)造一個宏觀的概念，使用思維導(dǎo)圖梳理。

再介紹之前，先簡短比較下RPC和消息隊列。RPC大多屬于請求-應(yīng)答模式，也包括越來越多響應(yīng)式范式，對于需要點對點交互、強事務(wù)保證和延遲敏感的服務(wù)/應(yīng)用之間的通信，RPC是優(yōu)于消息隊列的。那么消息隊列（下文也簡稱MQ，即Message Queueu）可以看做是一種異步RPC，把一次RPC變?yōu)閮纱?#xff0c;進(jìn)行內(nèi)容轉(zhuǎn)存，再在合適的時機(jī)投遞出去。消息隊列中間件往往是一個分布式系統(tǒng)，內(nèi)部組件間的通信仍然會用到RPC。

目前開源界用的比較多的選型包括，ActiveMQ、RabbitMQ、Kafka、阿里巴巴的Notify、MetaQ、RocketMQ。下文的技術(shù)點梳理也是學(xué)習(xí)借鑒了這些開源組件，然后萃取出一些通用技術(shù)點。

關(guān)于消息隊列的體系化認(rèn)知，見下方的思維導(dǎo)圖。

1. 整體架構(gòu)

一般分為producer，broker，consumer三者。

2. RPC通信

詳細(xì)參考《體系化認(rèn)識RPC》（http://www.infoq.com/cn/artic...）。

3. 高性能保證

主要考慮MQ的延遲和吞吐。

高性能投遞方面，分為producer和broker考慮。producer可以同步變異步、單條變批量保證發(fā)送端高性能，批量發(fā)送的觸發(fā)條件可以分為buffer滿或者時間窗口到了。broker可以進(jìn)行多topic劃分，再多分區(qū)/queue來進(jìn)行分治（Divide and Conquer）策略，加大并行度，分散投遞壓力。另外broker對于需要持久化的消息，可以使用順序IO，page cache，異步刷盤等技術(shù)提高性能，但是異步刷盤在掉電的情況下，可能會丟失數(shù)據(jù)，可以結(jié)合下面的高可用方案，在數(shù)據(jù)嚴(yán)格不丟和高性能吞吐之間做折中。

高性能消費，即consumer和broker通信，進(jìn)行推、拉消息。使用consumer group水平擴(kuò)展消費能力，需要按照業(yè)務(wù)場景使用分區(qū)有序或者無序消費。零拷貝技術(shù)節(jié)省broker端用戶態(tài)到內(nèi)核態(tài)的數(shù)據(jù)拷貝，直接從page cache發(fā)送到網(wǎng)絡(luò)，從而最大化發(fā)送性能。consumer批量pull，broker批量push。broker端還可以做消息過濾，可通過tag或者插件實現(xiàn)。

4. 高可用保證

主要針對broker而言。

集群高可用，producer通過broker投遞消息，所以必然有且僅有一個broker主負(fù)責(zé)“寫”，選主策略分為自動選主和非主動選擇，自動選主使用分布一致性組件完成，例如Kafka使用zookeeper，非自動選主，例如RocketMQ依賴多個無狀態(tài)的name server。

數(shù)據(jù)高可用，針對broker持久化積壓消息場景。可借助分布式存儲完成，但是往往性能上是個短板，所以大多數(shù)主流產(chǎn)品都進(jìn)行本地IO順序?qū)?#xff0c;進(jìn)行主從備份，多副本拷貝保證可用性，例如RocketMQ分為同步雙寫和異步復(fù)制，前者像HDFS一樣，寫完多個副本再返回producer成功，有一定性能損失，但不大，后者最大化性能，但是當(dāng)主掛的時候，數(shù)據(jù)有丟失風(fēng)險。

同樣，MQ集群也需要考慮跨機(jī)房高可用（非“異地多活”），broker的寫高可用，要考慮最小化MTTR，同時不阻塞consumer消費。

5. 擴(kuò)展性保證

采用分治（Divide and Conquer）策略，加大投遞和消費的并行度，多個topic、多個分區(qū)/queue、多個副本、多個slave或者鏡像。

6. 協(xié)議

producer、consumer和broker通信的協(xié)議，包括AMQP、STOMP、MQTT、HTTP、OpenWire（ActiveMQ）、XMPP、自定義等等。

AMQP是比較全面和復(fù)雜的一個協(xié)議，包括協(xié)議本身以及模型（broker、exchange、routing key等概念），目前RabbitMQ是AMQP消息隊列最有名的開源實現(xiàn)，有非常多語言已經(jīng)支持基于AMQP協(xié)議與消息隊列通信，同時還可以通過插件支持STOMP、MQTT等協(xié)議接入。Kafka、RocketMQ均使用自定義的協(xié)議。

7. 消費關(guān)系

包括三種

1) 點對點，也就是P2P，FIFO的隊列，可以看做單播。

2) Topic模式，Pub/Sub發(fā)布訂閱。

3) fanout廣播模式。

8. 消息堆積能力

持久化消息，如果存儲在本地磁盤，可以使用同步刷盤和異步刷盤兩種策略。磁盤不能無限堆積，會有清理策略，例如Kafka、RocketMQ都按照時間、數(shù)據(jù)量進(jìn)行retention。

非持久化，僅放在內(nèi)存，消費者處理完可選擇刪除掉。

9. 可靠投遞

對于producer，從API和I/O層面可使用同步、異步，對于吞吐層面可使用單條、批量。fire-and-forget模式，類似UDP，盡管發(fā)送即可。針對可能發(fā)生的錯誤，例如連接broker失敗，RPC超時、發(fā)布消息失敗、發(fā)布后無響應(yīng)，可選擇忽略或者重發(fā)，所以往往重復(fù)投遞的情況不可避免。

對于broker，如果要保證數(shù)據(jù)100%不丟，是可能的，但是需要犧牲下性能和吞吐，使用同步多寫、多副本策略+同步刷盤持久化消息，可以嚴(yán)格保證不丟。另外，broker對于寫入消息的payload，也會做完整性校驗，例如CRC等。

10. 可靠消費

消費次數(shù)，包括at most once、at least once、exactly once，其中前兩個比較好做到，最后的exactly once需要streaming consumer系統(tǒng)和broker端協(xié)作完成，例如storm的trident和flink。

推拉模式，push or pull。推模式最小化投遞延遲，但是沒有考慮consumer的承載能力，拉一般是輪詢接收broker的數(shù)據(jù)，按照consumer自己的能力消費。

消費記錄點，一般每個消息都有一個offset、ID或者時間戳，consumer可以按照這個offset來進(jìn)行定點消費以及消息重放。

消息確認(rèn)，consumer消費完成ACK回調(diào)broker或者集群高可用中間件（zk）通知消費進(jìn)度。

錯誤處理，對于消費失敗的情況，可以回復(fù)NACK，要求重發(fā)/requeue消息，當(dāng)錯誤超多一定閾值時候，放到死信隊列中。

消息重復(fù)消費，這和消費次數(shù)有關(guān)系，consumer在某些時候需要做到冪等性，保證重復(fù)消費不會引起業(yè)務(wù)異常。

11. 消息類型

順序消息，有序的話，分為分區(qū)有序或者全局有序，前者可以按照某個業(yè)務(wù)ID取模，在發(fā)送端發(fā)到不同的分區(qū)/queue即可，后者往往需要單個隊列才可以滿足。無序消費則可最大化吞吐。

定時消息，事務(wù)消息，例如RocketMQ均支持。

12. 消息查詢

目前RocketMQ支持消息根據(jù)msgId查詢。

13. 生態(tài)融合

客戶端語言的豐富性，與其他系統(tǒng)的集成度，例如Kafka和大數(shù)據(jù)技術(shù)棧融合很緊密，Spark、Storm、Flink、Kylin都有對應(yīng)的connector。

14. 管理工具

分布式系統(tǒng)的管理是提高生產(chǎn)效率的必備保障，一個好的系統(tǒng)，如果周邊工具不完善，對于使用者會很不友好，推廣也會有困難。

對于消息隊列，可以從topic管理、broker管理、集群管理、權(quán)限/配額管理、多租戶、客戶端工具、監(jiān)控、報警、控制臺Console UI來全方位進(jìn)行治理。

作者：neoremind 出處:http://neoremind.com/2018/03/...

---

• 分享一份阿里云內(nèi)部超全K8s實戰(zhàn)手冊，免費下載！
• 這里給大家再分享一些技術(shù)資料，建議收藏！
• 超全96頁！《阿里云ECS運維：linux系統(tǒng)診斷》手冊開放免費下載
• 升職加薪必備！運維工程師打怪升級進(jìn)階成神之路
• 我沒有開掛的人生！自律和堅持，是我走IT之路的唯一捷徑
• 全網(wǎng)最新、最全Linux面試題（2020版）！
• 史上最全、最新的Redis面試題（2020最新版）！
• 贊！7000 字學(xué)習(xí)筆記，MySQL 從入門到放棄
• 12800字！SQL 語法速成手冊（干貨滿滿，建議收藏！）

如有錯誤或其它問題，歡迎小伙伴留言評論、指正。如有幫助，歡迎點贊+轉(zhuǎn)發(fā)分享。

更多相關(guān)開源技術(shù)文章，請持續(xù)關(guān)注民工哥知乎技術(shù)專欄。

我是民工哥，一個愛折騰的IT技術(shù)老司機(jī)，歡迎關(guān)注我，我們一起學(xué)習(xí)，共同成長！！

總結(jié)

以上是生活随笔為你收集整理的消息队列 策略_消息队列技术点梳理（思维导图版）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。