核心組件
- Producer，消息生產者
- Consumer，消息消費者，負責消費消息，服務端向消費者推送消息或者消費者向服務端定時拉取消息。包括ConsumerGroup，邏輯概念通常消費一類的消息，且消費邏輯一致
- NameServer，元數據信息存儲，相當於註冊中心，集羣架構中的組織協調員
- Broker，是RocketMq核心是真正幹活的，專門負責消息的發送，接收，默認每10秒同步一次自身情況到Nameserver，否者超過兩分鐘認爲broker失效
- Topic，邏輯概念，不同類型的消息以不同的Topic進行區分，消息隊列用於存儲消息
消息的發送與接受
- 發送消息可分爲同步發送與異步發送
- 消息有多種訂閱模式， 例如需要接收某個topic中add類型的消息，
生產者設置：
Message message = newMessage("my-topic", "delete", msg.getBytes("UTF-8"));
消費者設置：
consumer.subscribe("my-topic", "add || update"); - 消息過濾
根據用戶自定義屬性進行過濾，過濾表達式類似於SQL的where，如：a> 5 AND b =‘abc’
RocketMQ之順序消息
一個topic可以有多個消息隊列，RocketMQ可以實現消息放到一個隊列裏面
RocketMQ之事務消息
- 生產者首先發送消息到MQ服務端，但是此消息被標記位“暫不能投遞”狀態，也就是半消息狀態。
- 等到MQ服務端接收到生產者提交的二次確認消息的時候，可能是commit或者Rollback，只有commit纔會進行向消費者投遞。
- 如果異常原因導致二次消息投遞失敗，MQ服務會主動詢問生成者消息的最終狀態，即消息回查。
- 消費者接收到消息執行邏輯後commit_success後流程結束，否者重試；重試參考消費者重試策略；
消費者獲取消息原理
消費者獲取消息是通過客戶端輪詢的方式來獲取的，但這種輪詢是長輪詢機制，沒有消息的時候會服務端阻塞請求，不會立即返回，等到有數據的時候纔會返回給客戶端，然後關閉連接。客戶端響應完消息之後再次向服務端發送新的請求，進入下一個循環週期。
消息模式
消費者通過DefaultMQPushConsumer將多個consumer組合在一起，消費發送到這個組分爲集羣模式與廣播模式：
- 集羣模式、是消費者負載均衡的策略，同一個ConsumerGroup所有的consumer組合起來纔是Topic內容的整體，每個consumer消費的只是一部分消息
- 廣播模式、 同一個ConsumerGroup裏的每個Consumer，都能消費訂閱到Topic的全部消息。同一個消息會被多次分發
集羣模式設置：
consumer.setMessageModel(MessageModel.CLUSTERING);
廣播模式設置：
consumer.setMessageModel(MessageModel.BROADCASTING);
RocketMQ消息存儲
- RocketMQ中的消息數據存儲，採用了零拷貝技術。
- RocketMQ寫入消息到磁盤的時候儘可能的保證順序寫入，順序寫入比隨機寫入效率高。
- RocketMQ消息的存儲是由ConsumeQueue和CommitLog配合完成的，CommitLog是真正存儲數據的文件，ConsumeQueue是索引文件，存儲指向真正數據的物理地址
存儲關係截圖：
![在這裏插入圖片描述]()
存儲關係流程圖：
![在這裏插入圖片描述]()
RocketMQ寫入消息到磁盤的模式
RocketMQ儘可能的順序寫入消息到磁盤，消息通過produer寫入消息到磁盤的時候有兩種寫磁盤的方式，一種是同步複製一種是異步刷盤：
- 同步複製、消息在寫入內存中後，會立即寫入磁盤、寫完磁盤完成之後纔會返回消息寫成功狀態
- 異步刷盤、在消息返回寫成功之後，消息只是寫入到內存中，當內存中消息積累到一定程度，統一觸發寫入磁盤
同步刷盤適合寫入高可靠性消息，異步刷盤適合高吞吐量不太重要的消息，可以通過broker配置文件中指定刷盤方式：
flushDiskType=ASYNC_FLUSH #異步
flushDiskType=SYNC_FLUSH #同步
消息重試機制
producer與consumer都可能發生重試，都可以自定義重試次數
- producer端重試只有在同步發送的情況下才會重試，而且是某些特定的異常纔會觸發重試
- consumer端重試分爲兩種、一個是exception，一個是timeout。消費者默認重試頻率5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h
2h。異常重試需要返回ConsumeConcurrentlyStatus.RECONSUME_LATER狀態，返回這個狀態的時候將會觸發重試。而超時重試的定義爲，MQ服務端沒有接到消息發反饋，既不是成功也不是失敗，這個時候就會定義超時。
集羣模式
- 多master模式、無slave，單臺宕機期間，這臺機器未被消費的消息不可訂閱，消息實時性收到影響
- 多master多slave模式，異步複製、master宕機消費者仍然可以通過slave消費，缺點是master宕機，磁盤損壞會有少量消息丟失
- 多master多slave模式，同步雙寫，優點master宕機，slave仍然可以提供消費，數據的可用性可靠性很高，缺點是性能比異步複製略低。