MongoDB复制集与Raft协议异同点分析
此文已由作者溫正湖授權(quán)網(wǎng)易云社區(qū)發(fā)布。
歡迎訪問網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運營經(jīng)驗。
一、日志復(fù)制流程：
a、raft leader節(jié)點在接收client請求后，先將請求寫到日志中，再將日志通過AppendEntries RPC發(fā)送到follow上。如果收到了大多數(shù)follow的確認消息，則對應(yīng)日志可以在leader節(jié)點回放，之后follow上對應(yīng)的日志也會被應(yīng)用；
b、mongodb primary節(jié)點在接收到client/driver請求后，將數(shù)據(jù)變化寫到數(shù)據(jù)庫上，同時寫一份日志到oplog.rs集合中，secondary節(jié)點通過tail cursor將日志從primary（或sync source，即復(fù)制源）拉取到本地馬上進行回放（不會像mysql relay一樣緩存到磁盤上），回放完成前將對應(yīng)的oplog日志保存到本節(jié)點的oplog.rs集合。
//顯然有幾點不一樣：
1、raft是主動推日志，mongodb是secondary拉日志； 相對來說，拉取的方式可以減輕主節(jié)點的負擔(dān)。這點mongodb好些。
2、raft先寫日志，日志發(fā)送到大多數(shù)節(jié)點后再應(yīng)用到狀態(tài)機。mongodb是先寫數(shù)據(jù)，然后寫日志，再通過日志拉取的方式應(yīng)用到從節(jié)點。 如果日志比數(shù)據(jù)小，那么raft更具有性能優(yōu)勢，否則，相差無幾。
二、什么時候返回客戶端：
a、raft中， 是大多數(shù)節(jié)點已收到，還是寫入leader日志時？ 通過“● Once new entry committed: ? Leader executes command in its state machine, returns result to client”這句話可以知道，raft是等大多數(shù)節(jié)點收到日志，leader將日志應(yīng)用到本節(jié)點后才返回客戶端；
b、mongodb中，什么時候返回客戶端可以由用戶進行動態(tài)設(shè)置，設(shè)置項為writeConcern，通過rs.conf()可以獲取當(dāng)前默認的writeConcern，默認置為w=1，即寫了primary后即返回。也可以在每次寫操作時設(shè)置writeConcern，主要包括寫入到幾個節(jié)點，寫入超時是多少，是否需要寫日志等。
// 所以，在這點上mongodb更加靈活，但早期設(shè)置的writeConcern級別太松，導(dǎo)致丟數(shù)據(jù)嚴重。目前設(shè)置為寫了primary節(jié)點再返回客戶端。
三、從節(jié)點什么時候應(yīng)用日志：
a、raft中，AppendEntries RPC攜帶了當(dāng)前已經(jīng)committed的log的信息，這樣從節(jié)點就可以根據(jù)該信息來將這之前的log應(yīng)用到本節(jié)點；
b、mongod中，從節(jié)點從復(fù)制源獲取oplog信息后，馬上在本節(jié)點并行回放；
//這點，mongod會更加簡潔。
四、誰能成為主節(jié)點：
a、raft，“Only servers with up-to-date logs can become leader”只有擁有最新數(shù)據(jù)的節(jié)點才能成為主。// 4.21更新，raft也是跟MongoDB復(fù)制集一樣，數(shù)據(jù)比大多數(shù)節(jié)點性就可以。官方ppt中的這句話，up-to-date翻譯成最新容易引起誤解。
b、數(shù)據(jù)比大多數(shù)節(jié)點新就可以成為主節(jié)點，新主節(jié)點在提供對外服務(wù)前，會有catchupTimeoutMills時間的catchup過程，用來短暫復(fù)制其他節(jié)點更新的數(shù)據(jù)；
//數(shù)據(jù)是否比大多數(shù)節(jié)點新，判斷依據(jù)是根據(jù)日志來的
五、如何確保每個節(jié)點在一個term中只投票一次：
a、raft “Each server gives only one vote per term (persist on disk)”，也就是說會將相應(yīng)信息持久化到磁盤上，具體可參考mongodb。
b、mongodb將投票信息持久化到local庫下replset.election中，內(nèi)容如：{ "_id" : ObjectId("58cbe1844857daa6e06ed9da"), "term" : NumberLong(4), "candidateIndex" : NumberLong(0) }，記錄了在那個term中給誰（candidateIndex）投票了。通過_id字段的ObjectId對象能獲取投票時間。
六、新主是否會做catchup：
a、raft，“Leader’s log is “the truth””，主節(jié)點的數(shù)據(jù)是真理，新主產(chǎn)生后，不會從存活的從節(jié)點上拷最新的數(shù)據(jù)；
b、mongodb，默認會有2s的catchup時間，如果發(fā)現(xiàn)從節(jié)點數(shù)據(jù)比新主新，那么在這時間內(nèi)會catchup
//兩則不同的原因是，mongodb是個AP系統(tǒng)，C無法滿足。存在2種情況，如果設(shè)置為w=1，那么如果主掛了，數(shù)據(jù)可能丟失。如果w=majority，那么如果還未滿足majority時，主掛了，也就是說客戶端返回錯誤，但這并不表示數(shù)據(jù)就寫入失敗了，需要等新主產(chǎn)生后進一步確認，因為即使新主本來沒有這部分數(shù)據(jù)，也可能在catchup節(jié)點從其他節(jié)點獲取。所以，這跟mysql等關(guān)系型數(shù)據(jù)庫不一樣。
七、主怎么知道從已經(jīng)收到日志/回放了：
a、raft，通過AppendEntries RPC返回結(jié)果；
b、通過replSetUpdatePosition命令；
replSetUpdatePosition不是周期性的，而是實時的。從節(jié)點每完成一次oplog回放，就向其復(fù)制源發(fā)送一個replSetUpdatePosition命令。
八、節(jié)點間是否有優(yōu)先級：
a、raft，大家都是平等的。
b、mongodb，有優(yōu)先級概念，priority可以是非負數(shù)。浮點型
九、是否支持鏈式復(fù)制：
a、raft，不支持；
b、mongodb支持鏈式復(fù)制。好處是減小了主上的壓力。尤其是在有很多從節(jié)點的場景下。不足之處是，這容易導(dǎo)致某些從節(jié)點的復(fù)制延遲過大。
網(wǎng)易云免費體驗館，0成本體驗20+款云產(chǎn)品！?
更多網(wǎng)易技術(shù)、產(chǎn)品、運營經(jīng)驗分享請點擊。
相關(guān)文章：
【推薦】?網(wǎng)易云容器服務(wù)微服務(wù)化實踐—微服務(wù)測試及鏡像化提測全流程實踐
【推薦】?流式斷言器AssertJ介紹
【推薦】?【網(wǎng)易嚴選】iOS持續(xù)集成打包（Jenkins+fastlane+nginx）
轉(zhuǎn)載于:https://www.cnblogs.com/zyfd/p/9814614.html
總結(jié)
以上是生活随笔為你收集整理的MongoDB复制集与Raft协议异同点分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： webpack4.0 babel配置遇到
- 下一篇： js for循环与for in循环的区别