没有最终一致性的事件溯源？答案

【问题标题】：Event Sourcing without eventual consistency?没有最终一致性的事件溯源？
【发布时间】：2018-01-16 11:36:04
【问题描述】：

我们即将放弃 ES，因为我们需要进程的一致读取模型，并且在尝试找出如何保存 ES 时，我们正在考虑一致的读取方面。基本上，一个命令将由 AR 运行，生成事件列表。这些事件将首先保存到事件存储中，然后（通过一些额外的编码）专门保存到读取模型（以事务方式，即来自单个命令的所有事件的所有投影都将包装在事务中）。只有在那之后，事件才会被发布。所以基本上我的代码是这样的：

void ExecuteCommand(Command cmd) {
   // validate and stuff...
   var events = GenerateEvents(cmd);
   PersistAllSync(events);
   ApplyProjectionsSync(events);
   PublishAsync(events)
}

除了明显的性能问题（一种分布式事务，基本上序列化所有命令）......为什么没有人这样做？

【问题讨论】：

如果出现错误，这可能会变得不一致。例如，假设ApplyProjectionsSync 成功，但随后PublishAsync 失败。这将创建读取模型发生更改但事件不在流中的情况。
您可能应该拼出这意味着什么；需要一致的读取模型实际上很不寻常。相信你需要他们保持一致，而你却不这样做是很常见的。
@Lev 你能解释一下为什么你需要一个一致的视图吗？只知道为什么我们可以通过事件溯源找到这样做的方法......
是的，人们正在这样做。它被称为关系数据库管理系统。你知道整个事件采购困扰我的是什么吗？您需要手动解决人们过去 50 年才解决的重要问题。这些人被称为数据库工程师。那么你有多大的信心能正确地做到这一点？

标签： cqrs event-sourcing

【解决方案1】：

我不是专家，但我可以尝试回答这个问题。

为了获得事务一致性，我将生成的事件分组（在相同的聚合/事务范围内）并将它们全部原子地应用于我的读取模型。而且我还发布分组为事务的事件。它对我来说很好，所以它当然是可能的。

为了避免本地读取模型的最终一致性（以便我可以在命令响应中返回新的一致状态），我还在事务中本地应用事件。只要您没有太多要更新的读取模型，我想这应该不是问题。如果您愿意，您可以为一些需要非最终更新和一致并以“正常”方式处理其余部分的读取模型使用此功能。

【讨论】：