RAFT作為協議可以僅支持領導人選舉嗎？

Question

我需要定期執行某些作業（例如每分鍾）。 如果單個節點執行此操作，則我們將出現單點故障。 為了避免這種情況，我在考慮以下方案：

1. Nodes form a raft cluster, with leader election
2. Only the leader executes scheduled jobs
     2.1. Every node checks if it is the leader before executing jobs.
3. Replication of commands is not required, thus we would not have a replicated log

為了實現這一目標，僅需選舉領導人。 那么有可能我只實施RAFT的領導人選舉部分並實現這一目標嗎？ 這種方法有什么問題嗎？

更新1以下是錯誤的假設：（不會發生）

*我可以看到的一個問題是：在網絡分區的情況下，可能有兩個領導者。 但這是我想忽略的事情。*

更新2：不需要重新啟動失敗的作業

注意：我可以使用Zookeeper或類似工具來實現此目的，但我的目的是編寫自己的

Answer 1

領導者選舉需要一個日志（領導者要做的第一件事是寫一個新的日志條目）和一些其他簿記持久狀態，因此即使您不復制任何命令，也將需要一個日志。 您不需要非常高效的日志或傳輸，但是否則，我認為您將要編寫筏紙中描述的大部分內容。

我建議您尋找一個庫或使用現有的服務（例如ZooKeeper或etcd）進行協調，但要說的是，如果您的系統可以應付正在同時運行的作業[在分區中，您表示可以忽略該情況]，那么您可以節省很多工作，並且只需始終在許多主機上運行它即可。

Answer 2

不，不需要日志。 領導者跟隨者候選狀態機和超時足以使主機知道其領導者。 （在這里嘗試https://raft.github.io/ ！）

但是，請注意，在很短的時間內，領導者並沒有意識到由於網絡分區等原因導致失去了領導權。

有兩種方法可以解決此問題。

A． 領導者只有在心跳定額得到最后確認后，才能在安全窗口內采取行動。 如更新所示，這有問題。

回想一下，有一個參數稱為選舉時間（election_timeout） ，另一個參數是不變的參數，我將其稱為hierbeat_timeout 。 領導者永遠不要在選舉時間超時后開始工作，因為它已收到最后一次定額更新MINUS，以便數據包在網絡中傳播。

|<- hearbeat_timeout ->|
|<---------------- election_timeout ------------------>|
                                   |<- safety_margin ->|
|<----- safe_time_to_do_work ----->|

B． 新當選領導人時，應等待一段時間再擔任領導人。

|<----------------- election_timeout ----------------->|
|<- hearbeat_timeout ->|
|<---- safety_margin ---->|
                          |<-- safe_time_to_do_work -->|

---

但是，您將需要記錄給定時間的領導者。 在應用程序日志或木筏本身中。

如果確實使用了筏日志，則即使每個字符串僅是“主機XYZ現在是領導者”字符串，也要確保每個領導者都提交了某些東西 ，因為筏有時會要求日志向前提交以提交先前的值。

---

更新 ：所有這些都有一些重要的微妙之處。 在某些情況下，過時的主持人很容易罷免領導者。

考慮主機沒有收到一些心跳的情況。 它的選舉計時器用盡了，並作為新一代的新候選人進行廣播。 這可以隨時發生，並且會使上述A的安全裕度無效。 筏中沒有什么可以防止這種情況的發生，我一直認為筏是其缺點。

如果您想保留方案A ，則可以修改協議，以便關注者拒絕心跳范圍內的選舉請求。 您還必須確保領導者在某個時候放棄控制權。 這將大大降低故障轉移的速度。