在 raft 中,当一个节点重新启动时,它会尝试重做所有日志条目以赶上状态。但是如果节点在恢复阶段再次宕机,节点会执行两次操作。如果操作不是幂等的,这两次重做操作将违反状态机。
根据上面的描述,我的问题是,在实践中使用 raft 的系统中是否需要使 ops 幂等?
在 raft 中,当一个节点重新启动时,它会尝试重做所有日志条目以赶上状态。但是如果节点在恢复阶段再次宕机,节点会执行两次操作。如果操作不是幂等的,这两次重做操作将违反状态机。
根据上面的描述,我的问题是,在实践中使用 raft 的系统中是否需要使 ops 幂等?
以我的经验,使用 Raft、Paxos 和朋友来实现分布式状态机和数据库(这是一个分布式状态机)。在这种情况下查看时,您真的,真的,真的希望条目是幂等的;否则你的状态机迟早会发散。
即使您使用的是无序队列(如 rabbit-mq 或 ActiveMQ),您也需要幂等性,因为它们最多只能保证一次交付。
当然,没有什么可以阻止您拥有非幂等条目。除了,也许是设计审查。简而言之,我想不出一种场景可以更好地为队列提供非幂等条目。不是一个。
是的,它们需要是幂等的和确定性的,因为在从属设备上执行操作应该使从属设备进入与主设备相同的状态。
这意味着操作无法读取外部状态(挂钟时间、随机数生成器),而只能使用当前状态机值和日志条目中的数据来决定下一个状态机值。
但是由于 raft 协议的设计,它提供了最多一次交付语义,因此不可能多次执行一个操作或将其写入复制日志。您无需像在仅提供至少一次交付语义的系统中那样检查此操作是否已执行
不,如果您使用 Paxos 或 Raft 等分布式共识算法,则不需要日志条目是幂等的。围绕幂等操作设计系统有很多优点,但并非总是可以这样做。分布式共识算法非常适合无法实现幂等性的情况,因此您需要确保在每个副本上最多处理一次操作。此外,它们让您确保在每个副本上始终以完全相同的顺序处理操作。这些是非常强大的属性,您需要执行一些相对昂贵的协调以确保它们保持不变,这就是为什么我们尽可能避免使用它们的原因。
分布式共识保证每个副本上的每个日志条目都是相同的,只要该日志条目已被大多数副本接受。每个副本只能处理已被大多数副本接受的日志条目,因为其他日志条目可能会在恢复期间发生更改。每个副本都必须仔细跟踪它已经处理了哪些操作,以避免在恢复期间再次处理它们。这很简单,因为日志是完全有序的,因此每个副本都可以使用一个数字来跟踪它已处理的操作,该数字表示最后处理的操作在日志中的位置。
事实上,另一种看待分布式共识的方式是,它是将幂等性(和交换性)重新添加到可能不是幂等性(或可交换性)的操作集合中的一种有效方法。所以不,操作不需要是幂等的,因为你可以从分布式共识算法中获得你需要的幂等性。