當(dāng)?leader?接收到消息請(qǐng)求生成?proposal?后就掛了，其他?follower?并沒有收到此?proposal，因此經(jīng)過恢復(fù)模式重新選了?leader?后，這條消息是被跳過的。?此時(shí)，之前掛了的?leader?重新啟動(dòng)并注冊(cè)成了?follower，他保留了被跳過消息的proposal?狀態(tài)，與整個(gè)系統(tǒng)的狀態(tài)是不一致的，需要將其刪除。

ZAB協(xié)議需要滿足上面兩種情況，就必須要設(shè)計(jì)一個(gè)leader選舉算法：能夠確保已經(jīng)被leader提交的事務(wù)Proposal能夠提交、同時(shí)丟棄已經(jīng)被跳過的事務(wù)Proposal。

針對(duì)這個(gè)要求

1. 如果leader選舉算法能夠保證新選舉出來的Leader服務(wù)器擁有集群中所有機(jī)器最高編號(hào)（ZXID最大）的事務(wù)Proposal，那么就可以保證這個(gè)新選舉出來的Leader一定具有已經(jīng)提交的提案。因?yàn)樗刑岚副?COMMIT?之前必須有超過半數(shù)的?follower ACK，即必須有超過半數(shù)節(jié)點(diǎn)的服務(wù)器的事務(wù)日志上有該提案的?proposal，因此，只要有合法數(shù)量的節(jié)點(diǎn)正常工作，就必然有一個(gè)節(jié)點(diǎn)保存了所有被?COMMIT?消息的?proposal?狀態(tài)

2. 另外一個(gè)，zxid是64位，高32位是epoch編號(hào)，每經(jīng)過一次Leader選舉產(chǎn)生一個(gè)新的leader，新的leader會(huì)將epoch號(hào)+1，低32位是消息計(jì)數(shù)器，每接收到一條消息這個(gè)值+1，新leader選舉后這個(gè)值重置為0.這樣設(shè)計(jì)的好處在于老的leader掛了以后重啟，它不會(huì)被選舉為leader，因此此時(shí)它的zxid肯定小于當(dāng)前新的leader。當(dāng)老的leader作為follower接入新的leader后，新的leader會(huì)讓它將所有的擁有舊的?epoch?號(hào)的未被?COMMIT?的?proposal?清除

?

總結(jié)

以上是生活随笔為你收集整理的被丢弃的消息不能再次出现的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。