前言：
在rockemq4.5之前，rocketmq集羣架構都是master-slave主從架構部署，如下圖，master節點負責寫入消息，slave節點負責同步master節點消息。假設master-1節點有個topic-A，此時如果master節點宕機無法恢復，此時我們是無法寫入topic-A消息的，這個時候rocketmq對於我們producer服務來說來說是不可用的，只有手動讓slave-1節點升級生master節點，服務纔可用。
試想一下，正好我們這個時候在做限時促銷活動，很多用戶參與，rocketmq服務突然不可用，手動恢復集羣花費的時間有很長，那損失得多大。
那麼有沒有一種辦法可以讓slave-1自動升級爲master對外提供服務呢？當然有，那就是rocketmq4.5版本提供的dledger集羣模式，接下來我們就會介紹一下rocketmq dledger 集羣模式。
Rocketmq dledger 集羣
dledger 使用的是raft協議，如果你之前瞭解過raft協議，那就很容易理解dledger的集羣架構原理。我們都知道raft協議有leader選舉， leader-follower 節點數據同步兩個功能，他能保證數據在多個節點的最終一致性。我們還是先直接介紹一下rocketmq dledger集羣架構吧，如下圖：
1. 一個broker集羣至少三個節點，一個leader節點，2個follower節點。
2.leader節點負責負責寫入消息，當消息寫入leader節點之後，leader會將消息同步到follower節點，當集羣過半數節點都寫入了消息，則提交這個消息。這種類似2pc的方式保證了主從最終一致性。
3.如果leader節點掛了，follower會在倒計時結束，觸發leader選舉，重新選舉一個新的leader節點負責寫入數據。
4.broker集羣的每個節點也都會向namesrv所有的節點進行註冊，這點和master-slave架構沒有任何區別。
在這裏大家會有一個疑問，dledger是如何進行leader選舉的，leader節點數據又如何同步到follower節點的呢？其實dledger是使用分佈式一致性協議raft實現了leader選舉和保證主從數據一致性，因此要介紹dledger原理，還是要從raft協議說起。
leader broker節點的選舉
dledger使用的是raft協議，它把mq集羣中的broker節點分爲三個角色：
leader節點 ：負責寫入數據，將數據同步到follower節點，保證主從數據一致性，同時使用心跳機制維護自己領導者地位；
follower節點：負責接受leader節點數據並保存到本地；響應leader節點心跳；
candidate節點：負責leader選舉。
當broker三個節點都啓動的時候，這個時候 他們全都是candidate 狀態，此時會觸發leader選舉，一般第一個先發起leader選舉的會當選成leader選舉，選舉步驟入下：
1.selfid-0，1，2三個節點剛啓動都是candidate狀態；
2.假設selfid-0 節點首先發起選舉，它會向selfid-1，2節點發起選舉請求，選舉自己當leader；發起選舉請求之前selftid-0會先投自己一票；
3.由於selfid-1，2節點還沒有發起選舉請求，他會同意selfid-0選舉請求，並給selfid-0節點一個確認回覆；
4.selfid-0節點收到過半數節點的同意答覆，則當選爲leader。
leader節點如何使用心跳維護領導者地位
selfid-0節點當選爲leader之後，首選要維護自己的leader者地位。他要告訴集羣其他節點，我是集羣中的leader，你們要成爲我的follower，負責同步我發給你們的數據；並且保證只要我還活着，你們就不要妄想重新進行選舉。具體步驟如下：
1.每個幾秒鐘leader節點會向所有follower節點發送心跳請求；
2.follower收到心跳請求之後，更新本地倒計時時間，同時給leader節點一個確認回覆；
3.leader節點收到過半數follower節點的回覆，則說明自己還是leader。
如果沒收到過半數follower節點回復，則會變更爲candidate狀態，重新觸發選舉；同樣的，如果follower節點沒收到
leader節點的心跳請求，follower節點也會變更爲candidate狀態，觸發leader選舉。
故障恢復
瞭解了dledger的心跳原理之後，就很容易明白故障恢復機制。看上面這張圖，假設此時leader節點故障掛掉，
follower節點收不到leader節點的心跳請求，那麼follower節點就會觸發leader選舉，選舉自己爲leader節點，這樣Rokcetmq 集羣又可以正常提供服務了。