假设我有一个X服务器的动态网络（不是随着时间的推移而固定），只有附加数据库中的所有事件的相同副本。现在，我想支持在这10台服务器中的任何一台上创建新事件，并让它们达成共识，复制事件，并且所有事件都会产生完全相同的事件顺序。我知道这是一个常见的问题，并且有一些算法应该处理这样的事情。但我并没有完全掌握它们，而且我对有关事件采购的共识存在一些问题。
我认为服务器永远不能完全确定它认为已达成共识的价值真的最终是“正确”值吗？我的基础是新服务器可以随时加入网络，并提供平衡以支持其他价值。这可能会在很晚的时候发生。但在这种情况下，服务器应如何处理新的“正确”值？在事件采购中，附加补偿事件以进行更正是正常的，但是这些补偿事件是否也不应该复制到所有服务器呢？确保所有服务器都具有完全相同的事件。
如果没有添加补偿事件，而只是“弹出”已经提交的事件，我们不必复制这些我猜，但后来我们会遇到其他问题。如果（错误地）提交的事件在事件总线上发送，以便其他服务可以对它们作出反应，我们不能只是从我们的事件数据库中弹出它们而不会弄乱它们。
或者，如果在一小段时间内达成共识后，真的承诺实现价值会更好吗？然后用冷手对待所有新/迟到的服务器？让他们接受结果呢？如果新服务器连接到比第一个更大的自己的网络并且他们都已经就另一个值达成共识会怎么样？
答案 0 :(得分：3)
我不知道你的分布式系统的背景是什么，但是已经建立了一致的算法（例如Raft，Paxos，Viewstamped Replication等），它们可以处理从集群中添加和删除服务器而不会影响提交事件
通常情况下，在多数人提交事件之前，您不会应用事件，特别是因为（如您所述）某些应用事件将具有外部可见性（例如，您从ATM机器上释放500美元）。因此，为了使服务器应用事件，它必须知道事件已经提交。此外，当服务器添加到系统时，必须使它们与已经提交的事件（）保持同步，并且它们可能不会选择不同的值。如果他们可以选择不同的值，系统将不再提供安全性。我建议阅读Raft论文。 Raft是一种可能适合您的共识算法，算法并不难理解。 Raft专门处理添加和删除服务器（参见第6节）。还有一个可以使用的Raft实现。
还有其他算法支持弱一致性和撤消操作，例如Bayou。您选择的算法最终取决于您的应用程序的需求。