升級Dledger高可用集群

一、主從架構的不足與Dledger的定位

1. 主從架構缺陷
   • 數據備份依賴Slave節點，但無自動故障轉移能力，Master宕機后需人工切換，期間消息可能無法讀取。
   • Slave僅存儲數據，無法主動升級為Master響應請求，集群高可用性不足。
2. Dledger的核心價值
   • 基于Raft協議實現自動選舉和數據強一致性，支持Leader節點故障時自動切換，保障服務連續性。
   • 解決傳統主從架構的“單點故障”和“腦裂問題”，提升集群可靠性。

二、Dledger集群架構與原理

1. 角色分工
   • Leader：唯一主節點，處理客戶端請求，通過日志復制同步數據到Follower。
   • Follower：從節點，接收并持久化Leader數據，參與選舉。
2. Raft協議關鍵機制
   • 選舉機制：候選人需獲得超過半數節點投票才能成為Leader，確保集群唯一主節點。
   • 任期（Term）：每個選舉周期生成唯一任期號，避免舊Leader干擾新選舉。
   • 心跳機制：Leader定期發送心跳維持統治，超時則觸發重新選舉。
   • 日志復制：Leader數據需多數Follower確認后才提交，保障強一致性。
3. 腦裂問題解決
   • 通過Raft協議的選舉規則和多數確認機制，確保同一時刻僅存在一個有效Leader，避免多主沖突。

三、Dledger集群搭建步驟（以3節點為例）

1. 環境配置
   • 3臺服務器（worker1、worker2、worker3），已部署NameServer集群，修改/etc/hosts綁定主機名。
   • 每個節點創建獨立存儲目錄（如/app/rocketmq/storeDledger），避免數據混淆。
2. 核心配置文件
   • 在conf/dledger/broker.conf中配置：

brokerClusterName=RaftCluster       # 集群名（統一標識）  
brokerName=RaftNode00              # 節點組名（同一集群內一致）  
listenPort=30911                   # 服務端口（避免與主從架構沖突）  
namesrvAddr=worker1:9876;worker2:9876;worker3:9876  # NameServer地址  
enableDLegerCommitLog=true         # 啟用Dledger功能  
dLegerGroup=RaftNode00             # Dledger組名（與brokerName一致）  
dLegerPeers=n0-worker1:40911;n1-worker2:40911;n2-worker3:40911  # 節點列表（格式：id-主機:端口）  
dLegerSelfId=n0                    # 當前節點ID（需在dLegerPeers中唯一，worker1設n0，worker2設n1，worker3設n2）  

1. 啟動與驗證
   • 各節點執行命令啟動Broker：

nohup bin/mqbroker -c conf/dledger/broker.conf &  

• • 通過Dashboard或mqadmin命令查看集群狀態，確認1個Leader和2個Follower。
  • 模擬故障：停止Leader節點，觀察剩余節點是否自動選舉新Leader（需保證≥2節點存活）。

四、Dledger與主從架構對比

維度	主從架構	Dledger集群
故障恢復	人工切換，服務中斷	自動選舉Leader，秒級恢復
數據一致性	異步復制（可能丟失少量數據）	強一致性（多數節點確認）
腦裂風險	存在	徹底避免（Raft協議保障）
運維成本	高（需手動管理主從狀態）	低（自動化管理）
性能影響	低	中（選舉和日志復制開銷）

五、注意事項與最佳實踐

1. 節點數量建議
   • 部署奇數個節點（如3/5個），容錯能力為(n-1)/2（3節點可容忍1個故障，5節點可容忍2個故障）。
2. 性能調優
   • 調整sendMessageThreadPoolNums為服務器CPU核心數，提升消息處理吞吐量。
   • 啟用異步刷盤（flushDiskType=ASYNC_FLUSH）降低延遲，但需權衡數據可靠性。
3. 生產環境建議
   • 關閉自動創建Topic（autoCreateTopicEnable=false），避免資源濫用。
   • 結合Prometheus+Grafana監控Leader選舉耗時、消息復制延遲等指標。

總結RocketMQ的運行架構

一、核心組件與功能

1. NameServer
   • 定位：集群的“大腦”，提供輕量級路由管理，不存儲狀態，節點間相互獨立。
   • 功能：
     • 接收Broker注冊信息，維護Topic與Broker的路由關系。
     • 為Producer和Consumer提供實時路由查詢服務。
2. Broker
   • 定位：核心數據節點，負責消息存儲、轉發與查詢，類似“硬盤”角色。
   • 分類：
     • Master：處理讀寫請求，支持數據同步到Slave。
     • Slave：備份Master數據，故障時可切換為只讀節點（主從架構）或自動升級為Leader（Dledger集群）。
3. Client（生產者/消費者）
   • 定位：集群的“輸入輸出設備”，通過NameServer獲取路由，與Broker直接交互。
   • 關鍵邏輯：
     • Producer：按負載均衡策略將消息發送到Topic的多個MessageQueue。
     • Consumer：通過Pull或Push模式從MessageQueue拉取消息，支持廣播模式和集群模式。

二、消息路由與存儲機制

1. Topic與MessageQueue
   • Topic：邏輯消息分類，數據分散存儲在多個MessageQueue中（默認8個隊列）。
   • MessageQueue：物理存儲單元，具有FIFO特性，消息按offset順序存儲。
2. 路由流程
   • Producer發送消息時，通過NameServer獲取Topic對應的Broker列表，按輪詢等策略選擇MessageQueue。
   • Consumer消費時，根據分配策略（如平均分配）綁定MessageQueue，維護本地消費進度（offset）。

三、集群模式對比

模式	主從架構	Dledger集群
路由更新	Broker主動向NameServer注冊	同上
高可用性	依賴人工切換	自動故障轉移
適用場景	中小規模業務、非核心場景	大規模集群、金融級高可靠場景

理解RocketMQ的消息模型

一、核心概念

1. 消息（Message）
   • 由Topic（主題）、Tag（標簽）、Body（內容）組成，支持屬性擴展（如事務ID、延遲時間）。
2. 消費者組（Consumer Group）
   • 同一組內消費者協同消費，支持負載均衡（集群模式）或獨立消費（廣播模式）。
   • 消費進度以組為單位存儲，不同組可獨立消費同一Topic。

二、消息投遞模式

1. 集群模式（默認）
   • 多個消費者實例分攤消費壓力，每條消息僅被組內一個實例處理。
   • 應用場景：訂單處理、實時數據分析。
2. 廣播模式
   • 每條消息被組內所有消費者實例消費，進度獨立管理。
   • 應用場景：配置更新通知、日志廣播。

三、消息存儲與消費流程

1. 存儲流程
   • Producer發送消息至Broker的MessageQueue，持久化到CommitLog文件。
   • Broker定期將CommitLog數據刷盤，并構建索引文件（ConsumeQueue、IndexFile）加速查詢。
2. 消費流程
   • Consumer從NameServer獲取Topic路由，拉取MessageQueue中的消息。
   • 消費成功后，更新本地offset（集群模式同步到Broker，廣播模式存儲于本地文件）。

四、與Kafka的對比

特性	RocketMQ	Kafka
消息順序	單個MessageQueue內有序	單個Partition內有序
事務支持	原生支持（兩階段提交）	需外部系統協調
多語言客戶端	官方支持Java、C++、Go等	依賴社區實現
管理工具	提供Dashboard可視化界面	依賴命令行或開源工具（如Kafka UI）

章節總結

一、核心知識回顧

1. 快速實戰
   • 掌握RocketMQ單機、主從、Dledger集群的搭建流程，調整JVM參數適應資源限制。
   • 使用命令行工具（tools.sh）和Java API實現消息收發，結合Dashboard監控集群狀態。
2. 架構設計
   • NameServer無狀態集群提供路由服務，Broker通過主從或Dledger實現高可用。
   • 消息模型基于Topic和MessageQueue，支持靈活的消費模式與負載均衡策略。
3. 核心特性
   • 事務消息、延遲隊列、死信隊列等功能滿足復雜業務需求（后續章節深入）。
   • Dledger集群通過Raft協議解決傳統主從架構的高可用短板，適合金融級場景。

二、延伸學習建議

1. 對比分析
   • 結合Kafka和RabbitMQ，理解不同MQ在吞吐量、可靠性、功能豐富度上的差異。
2. 生產實踐
   • 嘗試在Docker/Kubernetes中部署RocketMQ集群，實踐資源編排與彈性擴縮容。
   • 實現基于RocketMQ的分布式事務（如訂單支付場景），結合本地事務表保證最終一致性。
3. 源碼閱讀
   • 從org.apache.rocketmq.broker包入手，理解Broker啟動流程與消息存儲邏輯。