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