我正在用 golang 構(gòu)建一個(gè)我希望容錯(cuò)的應(yīng)用程序。我查看了不同的算法，如 RAFT 和 Paxos 以及它們在 golang 中的實(shí)現(xiàn)（etcd 的 raft，hashicorp 的 raft），但我覺得它們對于我的特定用例來說可能是矯枉過正。在我的應(yīng)用程序中，節(jié)點(diǎn)只是在待機(jī)狀態(tài)下等待，并在領(lǐng)導(dǎo)者失敗時(shí)充當(dāng)故障轉(zhuǎn)移。我不需要在整個(gè)集群中復(fù)制任何狀態(tài)。我只需要以下屬性：如果一個(gè)節(jié)點(diǎn)是領(lǐng)導(dǎo)者：運(yùn)行給定的代碼如果節(jié)點(diǎn)不是領(lǐng)導(dǎo)者：等待領(lǐng)導(dǎo)者失敗一旦現(xiàn)有領(lǐng)導(dǎo)者失敗，重新選舉領(lǐng)導(dǎo)者有什么建議么？
2 回答
至尊寶的傳說
TA貢獻(xiàn)1789條經(jīng)驗(yàn) 獲得超10個(gè)贊
由于您想要一個(gè)領(lǐng)導(dǎo)者選舉協(xié)議，因此聽起來您希望避免讓多個(gè)節(jié)點(diǎn)同時(shí)充當(dāng)領(lǐng)導(dǎo)者。答案實(shí)際上取決于您對該屬性的要求有多嚴(yán)格。在某些情況下，偶爾有多個(gè)節(jié)點(diǎn)充當(dāng)領(lǐng)導(dǎo)者是可以接受的；也許發(fā)生的最糟糕的事情是一些重復(fù)的工作。在其他情況下，如果有任何重復(fù)的領(lǐng)導(dǎo)者，整個(gè)系統(tǒng)可能會(huì)運(yùn)行不正確，因此您必須更加小心。
如果您可以接受偶爾出現(xiàn)重復(fù)領(lǐng)導(dǎo)者的情況，那么更簡單的協(xié)議可能適合您。但是，如果您絕對不能容忍同時(shí)擁有多個(gè)領(lǐng)導(dǎo)者，那么您將不得不將領(lǐng)導(dǎo)者選舉協(xié)議與某種狀態(tài)復(fù)制結(jié)合起來，而經(jīng)過驗(yàn)證的 Paxos 或 Raft 或類似的實(shí)現(xiàn)是一種非常好的方法。 . 有很多微妙不同的協(xié)議，但它們基本上都在做同樣的事情。
這里的基本問題是確定“一次”在現(xiàn)實(shí)網(wǎng)絡(luò)中的含義，其中有時(shí)可能會(huì)在很長的延遲后傳遞消息。通常假設(shè)網(wǎng)絡(luò)是完全異步的，沒有時(shí)間限制的交付，實(shí)際上 Paxos、Raft 等都被設(shè)計(jì)為在該假設(shè)下正常工作。這些算法通過定義自己的內(nèi)部時(shí)間概念（Paxos 中的選票，Raft 中的術(shù)語）并將這個(gè)“內(nèi)部時(shí)間”附加到它們控制下的所有狀態(tài)轉(zhuǎn)換來解決這個(gè)問題。這提供了一些非常強(qiáng)大的保證，特別是確保沒有兩個(gè)節(jié)點(diǎn)可以在同一“內(nèi)部時(shí)間”作為領(lǐng)導(dǎo)者采取行動(dòng)。
如果你不通過 Paxos 或 Raft 之類的東西復(fù)制任何狀態(tài)，那么你將無法利用這種強(qiáng)大的內(nèi)部時(shí)間概念。
陪伴而非守候
TA貢獻(xiàn)1757條經(jīng)驗(yàn) 獲得超8個(gè)贊
如果您要將客戶端部署在 Kubernetes 集群中以用于您的特定用例，則可以使用客戶端 go Kubernetes 庫。 https://github.com/kubernetes-client/go
- 2 回答
- 0 關(guān)注
- 157 瀏覽
添加回答
舉報(bào)
0/150
提交
取消