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 ，则可以修改协议，以便关注者拒绝心跳范围内的选举请求。 您还必须确保领导者在某个时候放弃控制权。 这将大大降低故障转移的速度。