RocketMQ調研筆記

RocketMQ調研筆記

毫無疑問，RocketMQ是目前最受歡迎的消息中間件之一，由淘寶中間件團隊研發，目前已經普遍應用於淘寶，天貓，螞蟻金服，口碑等各式各樣的複雜業務。

爲何選擇RocketMQ?

• 消息不丟失【重點】
• 穩定性高，吞吐量高，性能好
• 強大的技術團隊，健壯的社區力量
• 架構主輕量，組件無狀態
• 採用Java語言編寫，技術體系上更加契合

概念

Producer

消息生產者。生產者將業務應用系統產生的消息投遞到Broker機器上，投遞方式有同步，異步，單向等。

Producer Group：

消息生產者組。多個相同的生產者事例集羣爲一組。同一個生產者組的不一樣生產者實例能夠被Broker處理以提交或者回滾（事務保證）。生產者組只容許一個實例存在，即不支持生產者組的集羣處理。

Consumer

從Broker集羣上拉取消息進行處理。而且提供了兩種模型：

• 拉模型，consumer集羣主動從broker拉去數據
• 推模型，在拉模型的基礎上進行處理

Consumer Group

消息者組，支持負載均衡，容錯系統。消費者組的消費者實例必須具備徹底相同的topic訂閱。

Topic

topic是producer與consumer投遞消息與拉取消息的區分點，可是topic與producer與consumer之間的關係很是鬆散。具體而言，一個topic可能有零個，一個或多個向其發送消息的producer; 相反，producer能夠發送不一樣topic的信息。從consumer的角度來看，一個subject可能由零個，一個或多個consumer羣體訂閱。一樣，一個consumer羣體能夠訂閱一個或多個topic，只要這個羣體的實例保持其訂閱的一致性。

Broker

它接收producer發送的消息，存儲消息並準備處理來自consumer的請求(consumer拉模型)。它還存儲消息相關的元數據，包括消費者組，消費進度偏移和topic隊列信息。

Name Server

用來保存topic的路由信息。

• NameServer用來保存活躍的broker列表，包括Master和Slave。
• NameServer用來保存全部topic和該topic全部隊列的列表。
• NameServer用來保存全部broker的Filter列表。

消息模型

集羣、廣播

消息順序

有序：費消息有序意味着消息被消費者按照消息隊列發送的順序進行消費。若是您正在處理強制使用全局順序的狀況，請確保您使用的topic只有一個消息隊列。警告：若是指定消耗有序，則消費消息的最大併發度是消費者組訂閱的消息隊列的數量。 無序：同時使用消息時，消息消息的最大併發性僅受限於爲每一個客戶端指定的線程池。警告：在此模式下再也不保證消息順序。

RocketMQ架構設計

架構上分爲四個部分，由producer，consumer，namesrv以及broker組成。

生產者

SendStatus，包含於SendResult中，表示消息的投遞狀態

• FLUSH_DISK_TIMEOUT：表示若是Broker配置了FlushDiskType（刷盤策略）爲SYNC_FLUSH（同步刷盤），而且Broker在默認時間（syncFlushTimeout刷盤超時時間）內沒有完成刷新磁盤則返回該狀態。
• FLUSH_SLAVE_TIMEOUT：表示若是Broker配置了SYNC_MASTER，沒有在默認時間（syncFlushTimeout刷盤超時時間）內與主Broker完成同步，則返回該狀態。
• SLAVE_NOT_AVAILABLE：表示Broker配置了SYNC_MASTER，可是沒有配置從庫，則返回該狀態。
• SEND_OK：表示成功。可是它不表明這可靠，爲了確保不會丟失任何消息，您還應該啓用SYNC_MASTER或SYNC_FLUSH（指刷盤策略）。

Duplication or Missing

若是投遞消息失敗，返回狀態爲：FLUSH_DISK_TIMEOUT 或者 FLUSH_SLAVE_TIMEOUT

• 若是選擇繼續執行程序，則消息丟失。
• 不然選擇重發該消息，可是可能會致使消息重複。建議重發，由於能夠經過其餘手段來規避消息重複消費問題。

producer工做機制

producer按期從namesrv獲取可用的topic路由信息，包括可用的broker列表，並緩存在本地。producer發送消息時經過輪訓的方式從namesrv上拉取的路由信息中選擇一個可用的broker，根據某種策略把消息發送到該broker。若是namesrv掛掉，producer就使用本地的topic路由信息，若是此時producer重啓了，那就沒有topic路由信息了，也就沒法發送消息。

消費者

Consumer Group and Subscriptions

不一樣的Consumer Group能夠獨立消費相同的topic，而且在消費失敗以後均可以有各自的消費補償（重試機制）。 請確保同一個Consumer Group中的每一個consumer實例訂閱相同的topic。

MessageListener

• Orderly 能夠保證消息順序地被消費，由於它會將鎖住每個消息隊列並依次消費。若是不是對順序消息有極強的要求，不建議使用。異常請使用ConsumeConcurrentlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT
• Concurrently 不保證消息的順序問題，consumer同時拉取消息並消費。異常請使用：ConsumeConcurrentlyStatus.RECONSUME_LATER

ConsumeFromWhere 若是新建一個consumer group ，須要確認是否消費broker保存的歷史數據

• CONSUME_FROM_LAST_OFFSET將忽略歷史消息，並消耗以後產生的任何東西。
• CONSUME_FROM_FIRST_OFFSET將消耗Broker中存在的全部消息。
• CONSUME_FROM_TIMESTAMP消費在指定的時間戳以後產生的消息。

Duplication 重複消費

建議經過業務上的其餘手段來保證消息的不重複消費，由於在消息隊列在消費體系中有很是多的狀況會出現消息重複消費的問題。

服務註冊與發現

服務註冊與發現是一個無狀態的組件，即namesrv與namesrv相互隔離，沒有心跳檢查，沒有主從複製，沒有主從選舉等問題。

broker

brokerRole

• ASYNC_MASTER
• SYNC_MASTER
• SLAVE

若是用戶沒法容忍消息丟失，那麼建議用戶部署一個同步主庫並配上一個從庫來處理。若是用戶能夠容忍消息缺失可是必定要保證Broker的高可用狀態，那麼建議用戶部署一個異步主庫配置一個從庫來處理。若是用戶只想要簡單上手使用（不談高可用，零容錯等問題），建議用戶只須要配置一個異步主庫便可處理。

FlushDiskType

• ASYNC_FLUSH
• SYNC_FLUSH

推薦使用ASYNC_FLUSH，由於SYNC_FLUSH代價昂貴，會形成太多的性能損失。若是你想要可靠性，咱們建議你使用SYNC_MASTER和SLAVE。

broker工做機制

broker負責存儲消息，存儲隊列信息，維護消費進度，定時向namesrv上報topic路由信息。若是一臺broker掛掉，那producer不會立刻感知到，namesrv也不會當即把這個broker從它維護的可用broker列表摘除，而是要等到broker心跳超時後纔會摘除。摘除後，producer下次從namesrv獲取最新的可用的broker列表時，纔會發現此broker不存在了，而後也就不會再發送消息到此broker。在此以前broker掛掉的這段時間內，producer仍是會發消息到這個已經掛掉的broker的，可是producer內部有重試機制，若是發送到某個broker失敗幾回，那就會選擇其餘可用broker來發送。因此，對於用戶而言，最終發送消息都是成功的。broker到namesrv的心跳超時時間，以及producer到namesrv定時拉取topic路由信息的時間，均可配置。

弊端

• 主從複製不支持master選舉，master宕機後消息服務近乎不可用（slave可繼續消費舊的消息）
• 沒法作到真正意義上的讀寫分離，只有當master消費性能過低時（由RocketMQ決定）纔會將讀請求分攤到slave上
• 主從數據不一致，有可能形成數據重複消費