RocketMQ 學習筆記02-RocketMQ架構方案

1.設計理念

2.設計目標

2.1.架構模式

RocketMQ 與大部分消息中間件同樣,採用發佈訂閱模式,基本的參與組件包括:消息發送者、消息服務器、消息消費、路由發現。前端

2.2.順序消息

所謂順序消息,就是消息消費者按照消息到達消息存儲服務器的順序消費。RocketMQ 能夠保證消息嚴格有序。後端

2.3.消息過濾

消息過濾是指在消費消息時,消息消費者能夠對同一主題下的消息按照規則只消費本身感興趣的消息。RocketMQ 消息過濾支持在服務端與消費者端的消息過濾機制。服務器

  • 1.消息在broker 端過濾。broker 只將消息消費者感興趣的消息發送給消息消費者。
  • 2.消息在消費者端過濾,消息過濾方式徹底有消費者自定義,缺點是無用消息從Broker 傳輸到消費者端。

2.4消息存儲

消息中間件的一個核心實現是消息的存儲,對消息存儲通常有以下兩個緯度的度量: 消息堆積能力和消息存儲性能。RocketMQ追求消息存儲的高性能,引入內存映射機制全部主題的消息順序存儲在同一個文件中。同時爲了不消息無限在存儲服務器中累積,引入了消息文件的過時機制文件存儲空間報警機制架構

2.5 消息高可用

RocketMQ 在同步刷盤的方式下能夠保證消息不丟失;在異步刷盤模式下,會丟失少許消息。異步

2.6 消息到達(消費)低延遲

RocketMQ 在不發生消息堆積時,以常輪詢模式實現準實時消息的推送模式。性能

2.7 確保消息必須被消費一次

RocketMQ 經過消息消費確認機制(ACK)來確保消息至少被消費一次,單因爲ACK消息有可能丟失等其餘緣由,RocketMQ 沒法作到消息只被消費一次,有重複消費的可能。架構設計

2.8 回溯消息

回溯消息是是指消息消費者端已經消費成功的消息,因爲業務須要從新消費消息。RocketMQ支持按時間回溯消息,時間緯度可精確到毫秒,能夠向前向後回溯。設計

2.9 消息堆積

消息中間件的主要功能是異步解耦,必須具有對前端的數據洪峯,提升後端系統的可用性,必然要求對消息中間件具有必定的消息堆積能力。RocketMQ消息存儲文件並非永久存儲消息在服務器端,而是提供了過時機制,默認保留3天。code

2.10 定時消息

定時消息是指消息發送到Broker後,不能被消息消費者端當即消費,要到特定的時間點或者等待特定的時間後才能被消費。若是要支持任務精度的定時消息消費,必須在消息服務端對消息進行排序,勢必帶來很大的性能損耗,故RocketMQ不支持任意進度的定時消息,而只支持特定延遲級別。cdn

2.11 消息重試機制

消息重試是指消息在消費時,若是發送異常,消息中間件須要支持消息的從新投遞,RocketMQ支持重試機制。

3.架構設計

上面是RocketMQ的部署結構圖,操做流程以下介紹:

  • 一、啓動Namesrv,Namesrv起來後監聽端口,等待Broker、Produer、Consumer連上來,至關於一個路由控制中心。

  • 二、Broker啓動,跟全部的Namesrv保持長鏈接,定時發送心跳包。心跳包中包含當前Broker信息(IP+端口等)以及存儲全部topic信息。註冊成功後,namesrv集羣中就有Topic跟Broker的映射關係。

  • 三、收發消息前,先建立topic,建立topic時須要指定該topic要存儲在哪些Broker上。也能夠在發送消息時自動建立Topic。

  • 四、Producer發送消息,啓動時先跟Namesrv集羣中的其中一臺創建長鏈接,並從Namesrv中獲取當前發送的Topic存在哪些Broker上,而後跟對應的Broker建長鏈接,直接向Broker發消息。

  • 五、Consumer跟Producer相似。跟其中一臺Namesrv創建長鏈接,獲取當前訂閱Topic存在哪些Broker,而後直接跟Broker創建鏈接通道,開始消費消息。

RocketMQ消息生產者和消費者都是一個組的概念,自然支持集羣,這樣能夠應對大量的消息生產和消費,也是RocketMQ高吞吐量的一個標誌性特徵。

相關文章
相關標籤/搜索