這兩天一直在啃raft的論文，當(dāng)看到5.4.2節(jié)的時(shí)候，一直糾結(jié)raft是怎么解決上圖中這個(gè)問題。即序列c中s1在term4提交了索引2，但是序列d中s5卻在term5中提交了它的索引2，從而覆蓋了s1在term4中的索引2，破壞了Leader Completeness和State Machine Safety.
那么raft是如何解決這個(gè)問題的呢，它是只允許leader提交當(dāng)前term中的日志，而之前term中的日志由Log Matching性質(zhì)來保證。這樣能確保接收到日志的服務(wù)器的term是最新的，從而那些舊的服務(wù)器沒有機(jī)會(huì)競(jìng)爭到leader來改變這些已經(jīng)確認(rèn)過的日志。
上圖中的問題是，s1在term4提交了之前term2中的索引2，但是沒有成功提交索引3，此時(shí)那些接收了日志的服務(wù)器的最新term僅為2，導(dǎo)致s5有機(jī)會(huì)競(jìng)選到leader，并使用自己的索引2去覆蓋了s1的索引2。要解決這個(gè)問題的話就要使s1在提交了索引2后，使s5喪失競(jìng)爭到leader的機(jī)會(huì)，由于競(jìng)爭leader的規(guī)則是看誰的日志更新（即term和日志索引更高）。那么只要使s1在提交了索引2后，那些接受了s1索引2的服務(wù)器的日志比s5更新，就可以使s5得不到成為leader的機(jī)會(huì)。但是s1這條索引2日志的term僅僅為2，小于s5索引2日志的term為3。
解決辦法就是s1在term4期間，不去主動(dòng)提交索引2，而是通過提交索引3來間接提交索引2，這樣就能保證接收了s1日志的服務(wù)器的term是4，即最新的，s5就失去了競(jìng)選leader的機(jī)會(huì)，就沒有辦法來改變索引2了。
那么s1怎么通過提交索引3來間接提交索引2呢，答案就是Log Matching。Log Matching就是如果兩個(gè)服務(wù)器在相同位置的日志是相同的，那么這個(gè)位置之前的日志也是相同的。關(guān)于這個(gè)性質(zhì)是如何做到的，可以查看論文的第5.3節(jié)--日志復(fù)制。簡單地說就是leader在復(fù)制一條日志給服務(wù)器時(shí)，會(huì)順便檢查服務(wù)器上這條日志的前面一條日志是否和自己的一致。如果不一致的話leader就會(huì)將前面一條日志也復(fù)制給服務(wù)器，復(fù)制的過程中同樣也會(huì)執(zhí)行檢查前一條日志是否相同的操作。這樣的遞歸操作最終會(huì)保證leader和服務(wù)器上的所有日志一致。
raft論文的中文版地址
https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md
看論文有問題歡迎交流。
