RocketMQ是一個隊列模型的消息中間件，具有
- 高性能
- 高可靠
- 高實時
- 分佈式
採用java語言開發的分佈式的消息系統，阿里巴巴團隊開發，2016年底貢獻給apache。
模型
- 隊列模型
- 主題模型或發佈訂閱模型
在主題模型種，消息的生產者被成爲發佈者（Publisher），消息的消費者被稱爲訂閱者（Subscriber）,存放消息的容易被稱爲主題（topic）。
發佈者將消息發佈到指定的主題種，訂閱者需要提前訂閱主題才能接受特定主題的消息。
RocketMQ中的消息模型
- Producer Group 生產者組：代表某一類的生產者，比如多個秒殺系統作爲生產者，多個合在一起就是一個生產者組，一個生產者組通常產生相同的消息。
- Topic 主題：代表一類消息，比如訂單消息，物流消息等。
- Consumer Group 消費者組：代表某一類的消費者，比如多個短信系統作爲消費者，多個合在一起就是個一個消費者組，它們一般消費相同的消息。
主題中存在多個隊列，生產者每次生產消息之後是指定主題的某個隊列發送消息的。
消費位移：消息被一個消費者組消費之後是不會刪除的（因爲其他消費者組也需要），爲每個消費組維護一個消息位移。每次消費者組消費完會返回一個成功的響應，然後隊列再把維護的消費位移加一，這樣就不會出現消費被重複消費。
爲什麼一個主題中要維護多個隊列？提高併發能力。
RocketMQ在一個topic中配置多個隊列並且每個隊列維護每個消費者組的消費位置，實現了主題模式/發佈訂閱模式。
RocketMQ架構圖
Broker：負責消息的存儲，投遞和查詢以及服務高可用保證，就是消息隊列服務器。生產者生產消息到Broker，消費者從Broker拉取消息並消息。主從部署（master/slave），slave當時從master同步數據，master宕機，slave提供消費服務，但不能寫入信息。
NameServer：註冊中心。Borker管理和路由信息管理。Borker將自己的信息註冊NameServer，生產者和消費者定期查詢相關的Broker信息。作用：解耦，多個Broker保持負載均衡。通過單個Broker和所有的NameServer保持長連接，並且每隔30秒Broker會向所有的NameServer發送心跳，心跳包括自身的Topic配置信息。
Producer：消息發佈的角色，支持分佈式集羣方式部署，生產者。生產者需要向Broker發送消息的時候，需要先從NameServer獲取關於Broker的路由信息，然後通過輪詢的方法去向每個隊列中生產數據以達到負載均衡的效果。
Consumer：消息消費的角色，支持分佈式集羣方式部署。支持以push推，pull拉兩種模式對消息進行消費。消費者通過NameServer獲取所有Broker的路由消息後，向Broker發送pull請求來獲取消息數據。Consumer支持兩種方式啓動-廣播（Broadcast）和集羣(Cluster)。廣播模式下一個消息會發送給同一個消費組中的所有消費者，集羣模式下消息只會發送會一個消費者。
順序消費：普通順序（大多數情況）和嚴格順序（集羣中由一臺宕機則整個集羣不可用，主要場景用於binlog同步），Hash取模法？？？
重複消費：冪等：（任意多次執行所產生的影響均與一次執行的影響相同），結合具體業務,redis（天然支持冪等），數據庫插入法？？？
分佈式事務
事務要麼都執行要麼都不執行。比較常見的分佈式事務實現有2PC,TCC和事務消息（half半消息機制）？？？
RocketMQ中使用的是事務消息加上事務反查機制，
消息堆積問題
限流降級，判斷是否出現大量錯誤，
增加消費者實例同時增加每個主題的隊列數量，因爲一個隊列只會被一個消費者消費。
回溯消費
消費被消費後仍需要保留，重新消費一般是安裝時間維度。RocketMQ支持按時間回溯消費，可精確到毫秒。
RocketMQ的刷盤機制
同步刷盤和異步刷盤
同步複製和異步複製
同步刷盤和異步刷盤是在單個結點層面的，同步複製和異步複製是Broker主從模式下，主節點返回消息給客戶端的時候是否需要同步從節點。
存儲機制：
- commitLog：消息主體以及元數據的存儲主體，存儲
Producer端寫入的消息主體內容,消息內容不是定長的。單個文件大小默認1G ，文件名長度爲20位，左邊補零，剩餘爲起始偏移量，比如00000000000000000000代表了第一個文件，起始偏移量爲0，文件大小爲1G=1073741824；當第一個文件寫滿了，第二個文件爲00000000001073741824，起始偏移量爲1073741824，以此類推。消息主要是順序寫入日誌文件，當文件滿了，寫入下一個文件。 - ConsumeQueue：消息消費隊列，引入的目的主要是提高消息消費的性能。由於
RocketMQ是基於主題Topic的訂閱模式，消息消費是針對主題進行的，如果要遍歷commitlog文件中根據Topic檢索消息是非常低效的。Consumer即可根據ConsumeQueue來查找待消費的消息。其中，ConsumeQueue（邏輯消費隊列）作爲消費消息的索引，保存了指定Topic下的隊列消息在CommitLog中的起始物理偏移量offset**，消息大小size和消息Tag的HashCode值。consumequeue文件可以看成是基於topic的commitlog索引文件**，故consumequeue文件夾的組織方式如下：topic/queue/file三層組織結構，具體存儲路徑爲：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}。同樣consumequeue文件採取定長設計，每一個條目共20個字節，分別爲8字節的commitlog物理偏移量、4字節的消息長度、8字節taghashcode，單個文件由30W個條目組成，可以像數組一樣隨機訪問每一個條目，每個ConsumeQueue文件大小約5.72M； - IndexFile：
IndexFile（索引文件）提供了一種可以通過key或時間區間來查詢消息的方法。
內存映射機制？？？