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