当使用聚合事件采购作为交易范围时，您显然希望在单台计算机上拥有该聚合。但是，如果您还想构建高度可用且水平可伸缩的系统，则还需要在不同数据库上的许多计算机上复制此状态。事件采购多方面写？
如果在任何给定时刻只允许在该网络中的一台机器上有一个写入侧，其他机器最终可以是一致的读取侧。但为了最大限度地提高写入性能，我想最好是同时允许多个写入端。但是，像这样的系统如何处理一致性和共识？
当两台或多台机器想要同时更新通用但已复制的状态时，如何确保命令由所有写入端以相同顺序处理，以便生成的事件完全相同，并且还具有同样的顺序？ Lamport时钟是解决方案的一部分吗？
但是为了最大限度地提高写入性能，我想最好允许 多个写入同时进行。但是如何在这样的系统中处理一致性和共识？
在事件源系统中，写入侧的一致性总是很强。这通过使用乐观锁定由聚合和Event store强制执行：在并发写入的情况下（实际上事件仅附加到商店），则重试孔命令。这是可能的，因为聚合命令方法是纯粹的（无副作用）方法。只要事件没有持续下去，命令就可以重试。
当两台或多台计算机在同一时间更新状态（ 一个选择和坚持它？）
两个。第一个（总是有第一个）命令生成持久存储到该商店的事件。 secons命令由于低级别的conception异常而失败。然后通过加载+应用所有以前的事件重试，包括由第一个命令生成的事件。然后，第二个命令会生成也会持续存在的事件事件，如果新状态不允许处理第二个命令，则会引发异常。
您必须注意，第二个命令至少执行两次，但每次前面的事件（因此状态）都不相同。
基础架构将聚合版本附加到每个聚合流。每个事件附加增加此版本。聚合ID和版本有一个唯一的约束。这可能是所有活动商店的实施方式。
当一台机器行为不端（不知不觉，或故意），并传播 故障事件给网络的其余部分（如何检测呢？）
我不明白这是怎么发生，但如果它正在发生，那么它真的取决于你对故障事件的理解。您可以让一些Sagas/Process经理分析事件并触发一些发送给某种监督员的电子邮件。
我在Shuttle上处理的方式。回忆（无耻插件）ES的实现是在聚合ID 和上构建事件存储中版本的唯一聚集索引。通过这种方式，在同一个AR上的多次写入不会重叠，并且两个中的一个将“失去”。当然，这只能使用中央数据存储，但也许你的实现有一个类似的机制可用。
有多少客户端可以同时写入事件存储没有限制。然而，投影处理具有在单个机器上的每个命名投影为单个线程，因为事件排序非常敏感。那么，我猜可以在不同的机器上处理不同的预测。
感谢您的回答。我看到如何使用乐观锁定，当有一个单一的写入端。但是如果在不同的机器上有多个写方（没有一个公共数据库），他们会以某种方式必须同意要处理的命令。乐观锁定可以在一台机器上并发写入，但是如何处理扩展系统中的并发写入？ –
@AndreasZita没有一个共同的数据库，我不认为这是可能的。但是，使用通用数据库，您可以使用“Aggregate ID”进行分片。通过这种方式，您可以最小化共同写入的概率。 –