又是一年雙11季，土豪們買買買，程序員看看熱鬧，聊聊技術。海量的訂單、支付請求以及庫存更新等任務，離不開分布式架構（SOFAStack）、分布式數據庫（OceanBase）、分布式緩存（TAIr）、數據處理（Flink）等一系列框架的支持。而消息隊列作為連接這些組件的重要紐帶，可以實現各組件之間的異步通信和解耦。本文接下來就聊聊消息隊列那些事兒～
消息隊列給我們帶來什么？
消息中間件是分布式系統中重要的組件，主要解決應用解耦，異步消息，流量削峰等問題，實現高性能，高可用，可伸縮和最終一致性的系統架構。
- 應用解耦
在分布式系統中，服務之間可能會有依賴關系，如果直接進行服務調用，會增加服務之間的耦合度。使用消息隊列可以將服務之間的通信轉化為消息的發送和接收，降低服務之間的耦合度。
降低系統耦合性（源于網絡）
- 流量削峰/數據緩沖
在高并發場景下，瞬間的請求量可能會超出系統的承受能力，導致系統癱瘓。使用消息隊列可以實現流量削峰，將請求放入消息隊列中，由消費者服務異步消費請求，有效降低瞬間的請求量，保護系統穩定性。
削峰/限流（源于網絡）
- 異步處理：
在分布式系統中，不同服務之間的調用可能會因為網絡延遲或者服務負載高等原因導致調用時間較長。使用消息隊列可以實現異步處理，將請求放入消息隊列中，由消費者服務異步消費請求，提高系統的并發性和吞吐量。
異步提高性能（源于網絡）
常用的消息隊列框架？
目前在市面上比較主流的消息隊列中間件主要有，Kafka、ActiveMQ、RabbitMQ、RocketMQ 等這幾種。
RocketMQ和Kafka 都是高吞吐量、高可用的分布式消息隊列系統，相較于早期較活躍的ActiveMQ 和RabbitMQ 還是有著明顯優勢的，特別是在雙11這樣的場景，吞吐量的重要性是不言而喻的。
接下來從多個維度重點對RocketMQ與Kafka對比：
數據可靠性
- RocketMQ：支持異步實時刷盤、同步刷盤、同步復制、異步復制。“同步刷盤”，可以提高單機的可靠性，避免數據丟失。
- kafka：使用異步刷盤方式，異步復制/同步復制。采用的是異步刷盤的方式，可能會存在一定的數據丟失風險。不過，Kafka也提供了一些可靠性保障的機制，例如副本機制和ISR機制等，可以在一定程度上保證數據的可靠性。
在同步復制方面，RocketMQ可以利用IO組的commit機制，批量傳輸數據，因此性能上可能比Kafka要更好一些。而Kafka的同步復制是以partition為單位進行的，一個Kafka實例上可能有多個partition，這可能會影響性能。
單機支持的隊列數
- kafka單機若超過超過一定數量的partition/隊列，CPU load會發生明顯飆高，partition越多，CPU load越高，發消息的響應時間變長。
- RocketMQ單機支持最高5萬個隊列，CPU load不會發生明顯變化。
隊列多有什么好處呢？
單機可以創建更多個topic, 因為每個topic都是有一組隊列組成。
消費者的集群規模和隊列數成正比，隊列越多，消費類集群可以越大。
消息投遞的實時性
- kafka只支持pull模式，實時性取決于pull時間間隔（0.8以后版本支持長輪詢）
- rocketmq有pull（長輪詢）、push兩種模式 （雖然這個push模式是假push），push模式延遲肯定是比pull模式延遲低。
push模式是基于pull模式的，本地有個定時線程去pull broker的消息，緩存到本地，然后push到消費線程。
消費失敗重試
- Kafka本身不支持消費失敗重試，但是可以通過設置消費者的參數來實現重試機制。如，設置消費者的max.poll.retries
- RocketMQ消費失敗支持定時重試，每次重試間隔時間順延。
這里的重試指可靠的重試，即失敗重試的消息不是因為consumer宕機而導致的消息丟失。
嚴格保證消息有序
- kafka可保證同一個partition上的消息有序，但一旦broker宕機，就會產生消息亂序。
- Rocket支持嚴格的消息順序，一臺broker宕機，發送消息會失敗，但不會亂序。舉例：MySQL的二進制日志分發需要保證嚴格的順序。
定時消息
- kafka不支持定時消息
- 開源版本的RocketMQ僅支持定時級別，定時級別用戶可定制
分布式事務消息
- kafka不支持分布式事務消息
- RocketMQ支持分布式事務消息。
消息查詢
- Kafka本身不提供內置的消息查詢功能
- RocketMQ支持根據消息標識（發送消息時指定一個消息key, 任意字符串，如指定為訂單編號）查詢消息，也支持根據消息內容查詢消息。
消息回溯
- kafka可按照消息的offset來回溯消息
- RocketMQ支持按照時間來回溯消息，精度到毫秒，例如從一天的幾點幾分幾秒幾毫秒來重新消費消息。
RocketMQ按時間做回溯消息的典型應用場景為，consumer做訂單分析，但是由于程序邏輯或依賴的系統發生故障等原因，導致今天處理的消息全部無效，需要從昨天的零點重新處理。
消息并行度
- kafka的消息并行度，依賴于topic里配置的partition數，如果partition數為10，那么最多10臺機器來消費，每臺機器只能開啟一個線程；或者一臺機器消費，最多開啟10個線程。消費的并行度與partition個數一致。
- RocketMQ并行消費分兩種情況：1）順序消費方式的并行度與kafka一致；2）亂序消費方式的并行度取決于consumer的線程數，如topic配置10個隊列，10臺機器消費，每臺機器100個線程，那么并行度為1000。
消息隊列如何選型？
- ActiveMQ 的社區算是比較成熟，但是較目前來說，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。
- RabbitMQ 在吞吐量方面雖然稍遜于 Kafka、RocketMQ ，由于它基于 Erlang 開發，所以并發能力很強，性能極其好，延時很低，達到微秒級。但是也因為基于 Erlang 開發，所以國內很少有公司有實力做 Erlang 源碼級別的研究和定制。如果業務場景對并發量要求不是太高（十萬級、百萬級），那這幾種消息隊列中，RabbitMQ 或許是你的首選。
- RocketMQ 阿里開源，久經雙十一考驗，可以定制自己公司的 MQ。且支持事務消息，對消息一致性要求比較高的場景優先考慮。
- Kafka 的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展。同時 Kafka 最好是支撐較少的 topic 數量即可，保證其超高吞吐量。Kafka 唯一的一點劣勢是有可能消息重復消費，那么對數據準確性會造成極其輕微的影響，在大數據領域中以及日志采集中，這點輕微影響可以忽略這個特性天然適合大數據實時計算以及日志收集。如果是大數據領域的實時計算、日志采集等場景，用 Kafka 可謂是行業標準。
消息隊列常見問題
如何避免重復消費？如何保證冪等性?
冪等性：就是用戶對于同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點擊而產生了副作用問題
我們先來了解一下產生消息重復消費的原因，對于MQ的使用，有三個角色：生產者、MQ、消費者，那么消息的重復這三者會出現：
- 生產者：生產者可能會推送重復的數據到MQ中，有可能controller接口重復提交了兩次，也可能是重試機制導致的
- MQ：假設網絡出現了波動，消費者消費完一條消息后，發送ack時，MQ還沒來得及接受，突然掛了，導致MQ以為消費者還未消費該條消息，MQ回復后會再次推送了這條消息，導致出現重復消費。
- 消費者：消費者接收到消息后，正準備發送ack到MQ，突然消費者掛了，還沒得及發送ack，這時MQ以為消費者還沒消費該消息，消費者重啟后，MQ再次推送該條消息。
如何解決呢？在正常情況下，生產者是客戶，我們很難避免出現用戶重復點擊的情況，而MQ是允許存在多條一樣的消息，但消費者是不允許出現消費兩條一樣的數據，所以冪等性一般是在消費端實現的：
- 狀態判斷：消費者把消費消息記錄到redis中，再次消費時先到redis判斷是否存在該數據，存在則表示消費過，直接丟棄
- 業務判斷：消費完數據后，都是需要插入到數據庫中，使用數據庫的唯一約束防止重復消費。插入數據庫前先查詢是否存在該數據，存在則直接丟棄消息，這種方式是比較簡單粗暴地解決問題
如何解決消息丟失？
消息丟失屬于比較常見的問題。一般有生產端丟失、MQ服務丟失、消費端丟失等三種情況。針對各種情況應對方式也不一樣。
生產端丟失的解決方案主要有。
- 開啟confirm模式，生產著收到MQ發回的confirm確認之后，再進行消息刪除，否則消息重推。
- 生產者端消息保存的數據庫，由后臺定時程序異步推送，收到confirm確認則認為成功，否則消息重推，重推多次均未成功，則認為發送失敗。
MQ服務丟失則主要是開啟消息持久化，讓消息及時保存到磁盤。
消費端消息丟失則關閉自動ack確認，消息消費成功后手動發送ack確認。消息消費失敗，則重新消費。
（3）如何保證消息有序性
在生產端發布消息時，每次法發布消息都把上一條消息的ID記錄到消息體中，消費者接收到消息時，做如下操作：
- 先根據上一條Id去檢查是否存在上一條消息還沒被消費，如果不存在(消費后去掉id)，則正常進行，如果正常操作
- 如果存在，則根據id到數據庫檢查是否被消費，如果被消費，則正常操作
- 如果還沒被消費，則休眠一定時間(比如30ms)，再重新檢查，如被消費，則正常操作
- 如果還沒被消費，則拋出異常
（4） 如何解決消息積壓問題?
所謂的消息積壓，即生成者生成消息太快，而消費者處理消息太慢，從而導致消費端消息積壓在MQ中無法處理的問題。遇到這種消息積壓的情況，可以根據消息重要程度，分為兩種情況處理：
- 如果消息可以被丟棄，那么直接丟棄就好了
- 一般情況下，消息是不可以被丟棄的，這樣就需要考慮策略了，可以將原本的消費端重新部署為一個新的消息隊列（MQ）實例，并在后續增加消費端，以形成另一條生產-消息-消費的線路。
PS：實際項目中是否需要使用消息隊列以及如何使用，還是要根據業務特點進行選擇，一個UV沒幾個的系統，使用消息隊列，則純粹是老板掏錢、研發受罪了。
