架構

1. ZooKeeper：管理 Broker 注冊、分區 Leader 選舉及消費者組狀態。
2. Broker：存儲 Partition數據，每個 Partition 為獨立日志文件。
3. Producer/Consumer：通過 ZooKeeper獲取路由信息，實現消息分發與消費。

1. NameServer：無狀態路由中心，管理 Broker 地址與 Topic 隊列映射。
2. Broker：主從架構，Master 處理讀寫，Slave 異步/同步備份數據。
3. CommitLog：全局順序寫入消息體，ConsumeQueue 存儲消費偏移索引。

對比

RocketMQ 順序消息

生產者：單個生產者和串行發送
消息存儲：按照時間順序追加到commitlog中的，然后會被定時分發到cosumerQueue
分區順序：MQ生產者需要發送順序消息的時候，需要在send方法中傳入一個MessageQueueSelector，其中需要重寫一個select方法，這個方法就是用來定義要把消息發送到哪個MessageQueue的。這樣就實現了分區順序消息
全局順序：寫死一個隊列，讓所有的消息都發往這一個隊列中即可
順序消費：
1.分布式鎖保證了同一個消費組內，一個隊列只會被分配給一個消費者。
2.Synchronized這把鎖的目的就是為了保證同一時刻只有一個線程去消費這個隊列
3.ReentrantLock這把鎖的目的就是保證在重平衡過程中不會出現重復消費

RocketMQ事物消息

1. 發送half消息，探測MQ是否正常
2. half消息發送失敗，MQ故障，業務回滾
3. half消息成功，訂單系統執行自己的業務邏輯
4. 訂單系統執行本地事務失敗，則需要發送一個rollback請求給MQ，讓其刪除這條half消息
5. 如果訂單系統的本地事務執行正常，此時需要發送一個commit請求給MQ，要求MQ對之前的half消息進行commit操作，這樣庫存系統就可以消費這條消息了。

RocketMQ延時消息

存在不足
1.延時級別只有 18 個，并不能滿足所有場景，也不靈活；
2.延時時間不準確，后臺的定時線程可能會因為處理消息量大導致延時誤差大。

為了彌補延時消息的不足，引入了定時消息，60s 的時間輪，但是對于所有的時間延時，都是支持的。可以在每個時間節點增加一個 round 字段，記錄時間輪轉動的圈數，時間輪算法的優勢是不用去遍歷所有的任務，每一個時間節點上的任務用鏈表串起來，當時間輪上的指針移動到當前的時間時，這個時間節點上的全部任務都執行。