消息中間件之RocketMQ簡介（系列一）

什麼是消息中間件

消息（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（無單點故障）