什麼是消息中間件
消息（Message）是指在應用間傳送的數據。消息可以非常簡單，比如至包含文本字符串、JSON等，當然了，也可以很複雜，比如內嵌對象。
消息隊列中間件（Message Queue Middleware，簡稱 MQ）是指利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，並基於數據通信來進行分佈式系統的集成。通過提供消息傳遞和消息排隊模型，它可以在分佈式環境下擴展進程間的通信。
目前開源的消息中間件有很多，比較主流的有RabbitMQ、Kafka、ActiveMQ、RocketMQ等
消息中間件的分類
推消息模型（PUSH）
消息生產者將消息發送給消息傳遞服務，消息傳遞服務又將消息推給消息消費者。
拉消息模型(PULL)
消費者請求消息服務請求消息，消息生產者從消息中間件拉此消息。
兩者的區別：
模型 | push | pull |
服務端 | 消息存儲 處理請求 保存推送軌跡 保存訂閱關係 消費者負載均衡 集中式 | 消息存儲 處理請求 分佈式 |
客戶端 | 處理響應和請求 | 處理響應和請求 保存pull狀態，如拉取位置的偏移量offset 異常情況下的消息暫存 |
實時性 | 較好，收到數據後可立即發送給客戶端 | 取決於pull的時間間隔 |
消費者故障 | 消費者故障情況下，服務端堆積消息，重複推送耗費資源 保存推送軌跡壓力很大 | 消費者故障，對服務端無影響 |
其他 | 對消息推送有更多控制，能實現多樣化的推送機制，當消費者數量增多的時候，推送壓力大，性能天花板，消費者處理能力差異，導致堆積消息 | 需要在客戶端實現消息過濾，浪費資源 需要在不同客戶端之間協調，做負載均衡 |
消息中間件的應用場景
l可恢復性
譬如跨機房數據複製
l異步通信
用戶註冊發郵件和短信
l流量削峯
諸如大促、秒殺活動等
另也可用於性能壓測
l順序保證
比如在支付系統中，處理順序就很重要
l解耦
例如：電商系統中用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的接口；這時若訂單系統故障，則庫存系統就會失敗，從而導致訂單失敗，同時也出現耦合度高，使用消息中間件；下單系統和庫存系統可以單獨分開設計，做到應用解耦。
l日誌收集
計算PV、用戶行爲分析
RocketMQ簡介
阿里的消息中間有很長的歷史，從2007年的notify到2010年的Napoli，2011年升級後改爲MetaQ，然後到2012年開始做RocketMQ，RocketMQ使用Java語言開發，於2016年開源。第一代的Notify主要使用了推模型，解決了事務消息；第二代的MetaQ主要使用了拉模型，解決了順序消息和海量堆積的問題。RocketMQ基於長輪詢的拉取方式，兼有兩者的優點。
目前RocketMQ已經成爲Apache頂級項目。在阿里內部，RocketMQ很好地服務了集團大大小小上千個應用，在每年的雙11當天，有萬億級消息通過RocketMQ流轉（在2017年雙11當天，RocketMQ流轉的線上消息達到了萬億級，峯值TPS達到5600萬），在阿里大中臺上也發揮了一定的作用。
RocketMQ的特點
l是一個隊列模型的消息中間件，具有高性能、高可靠、高實時、分佈式特點
lProducer、Consumer、隊列都可以分佈式
l能夠保證嚴格的消息順序
l提供豐富的消息拉取模式
l高效的訂閱者水平擴展能力
l實時的消息訂閱機制
l億級消息堆積能力
l較少的依賴
RocketMQ物理部署結構
如上圖所示， RocketMQ的部署結構有以下特點：
lName Server是一個幾乎無狀態節點，可集羣部署，節點之間無任何信息同步。
lBroker部署相對複雜，Broker分爲Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave的對應關係通過指定相同的BrokerName，不同的BrokerId來定義，BrokerId爲0表示Master，非0表示Slave。Master也可以部署多個。每個Broker與Name Server集羣中的所有節點建立長連接，定時註冊Topic信息到所有Name Server。
lProducer與Name Server集羣中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，並向提供Topic服務的Master建立長連接，且定時向Master發送心跳。Producer完全無狀態，可集羣部署。
lConsumer與Name Server集羣中的其中一個節點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，並向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規則由Broker配置決定。
RocketMQ邏輯部署結構
如上圖所示，RocketMQ的邏輯部署結構有Producer和Consumer兩個特點。
Producer Group
用來表示一個發送消息應用，一個Producer Group下包含多個Producer實例，可以是多臺機器，也可以是一臺機器的多個進程，或者一個進程的多個Producer對象。一個Producer Group可以發送多個Topic消息，Producer Group作用如下：
1. 標識一類Producer
2. 可以通過運維工具查詢這個發送消息應用下有多個Producer實例
3. 發送分佈式事務消息時，如果Producer中途意外宕機，Broker會主動回調Producer Group內的任意一臺機器來確認事務狀態。
Consumer Group
用來表示一個消費消息應用，一個Consumer Group下包含多個Consumer實例，可以是多臺機器，也可以是多個進程，或者是一個進程的多個Consumer對象。一個Consumer Group下的多個Consumer以均攤方式消費消息，如果設置爲廣播方式，那麼這個Consumer Group下的每個實例都消費全量數據。
常用RocketMQ集羣模式
n單master模式
也就是隻有一個master節點，稱不上是集羣，一旦這個master節點宕機，那麼整個服務就不可用，適合個人學習使用。
n多Master模式
多個master節點組成集羣，單個master節點宕機或者重啓對應用沒有影響。
【優點】所有模式中性能最高
【缺點】單個master節點宕機期間，未被消費的消息在節點恢復之前不可用，消息的實時性就受到影響。
注意：使用同步刷盤可以保證消息不丟失，同時Topic相對應的queue應該分佈在集羣中各個節點，而不是隻在某各節點上，否則，該節點宕機會對訂閱該topic的應用造成影響。
n多Master多slave異步複製模式
在多master模式的基礎上，每個master節點都有至少一個對應的slave。master
節點可讀可寫，但是slave只能讀不能寫，類似於mysql的主備模式。
【優點】在master宕機時，消費者可以從slave讀取消息，消息的實時性不會受影響，性能幾乎和多master一樣。
【缺點】使用異步複製的同步方式有可能會有消息丟失的問題。
n多Master多Slave同步複製雙寫模式
同多 master多slave異步複製模式類似，區別在於master和slave之間的數據同步方式。
【優點】同步雙寫的同步模式能保證數據不丟失。
【缺點】發送單個消息RT會略長，性能相比異步複製低10%左右。
【刷盤策略】同步刷盤和異步刷盤（指的是節點自身數據是同步還是異步存儲）
【同步方式】同步雙寫和異步複製（指的一組master和slave之間數據的同步）
注意：要保證數據可靠，需採用同步刷盤和同步雙寫的方式，但性能會較其他方式低
集羣模式總結
單Master無Slave（脆弱）
單master多Slave（單點故障就癱瘓，開源版本無主備切換功能）
多Master無Slave（無單點故障，prod環境常用）
多Master和Slave（無單點故障）