消息队列 策略_消息队列技术点梳理（思维导图版）
消息隊列作為服務/應用之間的通信中間件，可以起到業務耦合、廣播消息、保證最終一致性以及錯峰流控（克服短板瓶頸）等作用。本文不打算詳細深入講解消息隊列，而是體系化的梳理消息隊列可能涉及的技術點，起到提綱挈領的作用，構造一個宏觀的概念，使用思維導圖梳理。
再介紹之前，先簡短比較下RPC和消息隊列。RPC大多屬于請求-應答模式，也包括越來越多響應式范式，對于需要點對點交互、強事務保證和延遲敏感的服務/應用之間的通信，RPC是優于消息隊列的。那么消息隊列（下文也簡稱MQ，即Message Queueu）可以看做是一種異步RPC，把一次RPC變為兩次，進行內容轉存，再在合適的時機投遞出去。消息隊列中間件往往是一個分布式系統，內部組件間的通信仍然會用到RPC。
目前開源界用的比較多的選型包括，ActiveMQ、RabbitMQ、Kafka、阿里巴巴的Notify、MetaQ、RocketMQ。下文的技術點梳理也是學習借鑒了這些開源組件，然后萃取出一些通用技術點。
關于消息隊列的體系化認知，見下方的思維導圖。
1. 整體架構
一般分為producer，broker，consumer三者。
2. RPC通信
詳細參考《體系化認識RPC》（http://www.infoq.com/cn/artic...）。
3. 高性能保證
主要考慮MQ的延遲和吞吐。
高性能投遞方面，分為producer和broker考慮。producer可以同步變異步、單條變批量保證發送端高性能，批量發送的觸發條件可以分為buffer滿或者時間窗口到了。broker可以進行多topic劃分，再多分區/queue來進行分治（Divide and Conquer）策略，加大并行度，分散投遞壓力。另外broker對于需要持久化的消息，可以使用順序IO，page cache，異步刷盤等技術提高性能，但是異步刷盤在掉電的情況下，可能會丟失數據，可以結合下面的高可用方案，在數據嚴格不丟和高性能吞吐之間做折中。
高性能消費，即consumer和broker通信，進行推、拉消息。使用consumer group水平擴展消費能力，需要按照業務場景使用分區有序或者無序消費。零拷貝技術節省broker端用戶態到內核態的數據拷貝，直接從page cache發送到網絡，從而最大化發送性能。consumer批量pull，broker批量push。broker端還可以做消息過濾，可通過tag或者插件實現。
4. 高可用保證
主要針對broker而言。
集群高可用，producer通過broker投遞消息，所以必然有且僅有一個broker主負責“寫”，選主策略分為自動選主和非主動選擇，自動選主使用分布一致性組件完成，例如Kafka使用zookeeper，非自動選主，例如RocketMQ依賴多個無狀態的name server。
數據高可用，針對broker持久化積壓消息場景?？山柚植际酱鎯ν瓿?#xff0c;但是往往性能上是個短板，所以大多數主流產品都進行本地IO順序寫，進行主從備份，多副本拷貝保證可用性，例如RocketMQ分為同步雙寫和異步復制，前者像HDFS一樣，寫完多個副本再返回producer成功，有一定性能損失，但不大，后者最大化性能，但是當主掛的時候，數據有丟失風險。
同樣，MQ集群也需要考慮跨機房高可用（非“異地多活”），broker的寫高可用，要考慮最小化MTTR，同時不阻塞consumer消費。
5. 擴展性保證
采用分治（Divide and Conquer）策略，加大投遞和消費的并行度，多個topic、多個分區/queue、多個副本、多個slave或者鏡像。
6. 協議
producer、consumer和broker通信的協議，包括AMQP、STOMP、MQTT、HTTP、OpenWire（ActiveMQ）、XMPP、自定義等等。
AMQP是比較全面和復雜的一個協議，包括協議本身以及模型（broker、exchange、routing key等概念），目前RabbitMQ是AMQP消息隊列最有名的開源實現，有非常多語言已經支持基于AMQP協議與消息隊列通信，同時還可以通過插件支持STOMP、MQTT等協議接入。Kafka、RocketMQ均使用自定義的協議。
7. 消費關系
包括三種
1) 點對點，也就是P2P，FIFO的隊列，可以看做單播。
2) Topic模式，Pub/Sub發布訂閱。
3) fanout廣播模式。
8. 消息堆積能力
持久化消息，如果存儲在本地磁盤，可以使用同步刷盤和異步刷盤兩種策略。磁盤不能無限堆積，會有清理策略，例如Kafka、RocketMQ都按照時間、數據量進行retention。
非持久化，僅放在內存，消費者處理完可選擇刪除掉。
9. 可靠投遞
對于producer，從API和I/O層面可使用同步、異步，對于吞吐層面可使用單條、批量。fire-and-forget模式，類似UDP，盡管發送即可。針對可能發生的錯誤，例如連接broker失敗，RPC超時、發布消息失敗、發布后無響應，可選擇忽略或者重發，所以往往重復投遞的情況不可避免。
對于broker，如果要保證數據100%不丟，是可能的，但是需要犧牲下性能和吞吐，使用同步多寫、多副本策略+同步刷盤持久化消息，可以嚴格保證不丟。另外，broker對于寫入消息的payload，也會做完整性校驗，例如CRC等。
10. 可靠消費
消費次數，包括at most once、at least once、exactly once，其中前兩個比較好做到，最后的exactly once需要streaming consumer系統和broker端協作完成，例如storm的trident和flink。
推拉模式，push or pull。推模式最小化投遞延遲，但是沒有考慮consumer的承載能力，拉一般是輪詢接收broker的數據，按照consumer自己的能力消費。
消費記錄點，一般每個消息都有一個offset、ID或者時間戳，consumer可以按照這個offset來進行定點消費以及消息重放。
消息確認，consumer消費完成ACK回調broker或者集群高可用中間件（zk）通知消費進度。
錯誤處理，對于消費失敗的情況，可以回復NACK，要求重發/requeue消息，當錯誤超多一定閾值時候，放到死信隊列中。
消息重復消費，這和消費次數有關系，consumer在某些時候需要做到冪等性，保證重復消費不會引起業務異常。
11. 消息類型
順序消息，有序的話，分為分區有序或者全局有序，前者可以按照某個業務ID取模，在發送端發到不同的分區/queue即可，后者往往需要單個隊列才可以滿足。無序消費則可最大化吞吐。
定時消息，事務消息，例如RocketMQ均支持。
12. 消息查詢
目前RocketMQ支持消息根據msgId查詢。
13. 生態融合
客戶端語言的豐富性，與其他系統的集成度，例如Kafka和大數據技術棧融合很緊密，Spark、Storm、Flink、Kylin都有對應的connector。
14. 管理工具
分布式系統的管理是提高生產效率的必備保障，一個好的系統，如果周邊工具不完善，對于使用者會很不友好，推廣也會有困難。
對于消息隊列，可以從topic管理、broker管理、集群管理、權限/配額管理、多租戶、客戶端工具、監控、報警、控制臺Console UI來全方位進行治理。
作者：neoremind 出處:http://neoremind.com/2018/03/...
- 分享一份阿里云內部超全K8s實戰手冊，免費下載！
- 這里給大家再分享一些技術資料，建議收藏！
- 超全96頁！《阿里云ECS運維：linux系統診斷》手冊開放免費下載
- 升職加薪必備！運維工程師打怪升級進階成神之路
- 我沒有開掛的人生！自律和堅持，是我走IT之路的唯一捷徑
- 全網最新、最全Linux面試題（2020版）！
- 史上最全、最新的Redis面試題（2020最新版）！
- 贊！7000 字學習筆記，MySQL 從入門到放棄
- 12800字！SQL 語法速成手冊（干貨滿滿，建議收藏！）
如有錯誤或其它問題，歡迎小伙伴留言評論、指正。如有幫助，歡迎點贊+轉發分享。
更多相關開源技術文章，請持續關注民工哥知乎技術專欄。
我是民工哥，一個愛折騰的IT技術老司機，歡迎關注我，我們一起學習，共同成長！！
總結
以上是生活随笔為你收集整理的消息队列 策略_消息队列技术点梳理（思维导图版）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hc05与单片机连接图_单片机科普：单片
- 下一篇： 一般向量空间的基变换_从希尔伯特空间的角