cqrs - 在事件存储中保留每个聚合的最新版本的快照

Question

我们目前正在使用 SQL 支持的事件存储(典型的 2 表实现)，团队中的一些人担心即使我们仅将事件存储用于写入，事情可能会变慢一点，所以建议不是到处添加快照，而是实际维护每个聚合的最新状态(JSON 格式)的完全一致(与事件流)快照。系统上的所有查询最终都将在读取端完成，典型的 SQL 数据库从 ES(写入)端以最终一致性方式更新。

拥有这样一个系统将使我们能够享受拥有 Event Store 的好处，同时完全消除任何可能的性能问题。我们目前没有使用任何“时间旅行”功能，尽管迟早会出现这种情况。

这是一个好方法吗？里面有些东西让我不舒服。例如，如果我们需要某种时间旅行功能，那么在每个聚合的事件流中没有随处可见的快照将证明是性能灾难。当然，我们既可以拥有每个聚合实例的最新快照，也可以拥有整个事件流的快照。

如果我们决定沿着这条路线走下去，我们应该使给定聚合的快照更新与同一聚合上的事件更新事务相关，还是应该只更新事件并以最终一致的方式更新快照？

这种方法的缺点是什么？有没有人尝试过类似的东西？

Answer 1

在向系统添加不必要的复杂性之前，您可能应该运行自己的基准测试。当需要查询和应用数千个事件以从事件流重建聚合时，我们注意到了一些性能问题，其中 JSON 到对象反序列化是最大的性能瓶颈。如果您的每个聚合只有很少的事件(例如 < 100)，您可能不会注意到实践中的任何显着差异。

大多数事件存储每隔 n 记录一次快照事件/提交，比如每 50-100 个事件，并在组装时查询最新的快照并应用自上次快照以来丢失的事件。如果您还将所有旧快照保留在您的快照数据库中，时间旅行功能将与通常的查询一样快，并且您只需要稍微多一点的持久性空间，这在现在很便宜。

快照应该始终从原始事务中写出(并且可以在另一个线程中生成)，因为如果缺少最后一个快照，这并不重要，但是您不希望您的业务事务由于错误而失败快照写入事务。

根据您通常的系统正常运行时间和数据大小，将快照保存在内存或分布式缓存/graid 或其他数据库(非 SQL)中可能是有意义的。