J Oliver EventStore V2.0 问题

Question

我正在着手实施一个使用 CQRS 的项目，并打算使用 J Oliver EventStore V2.0 作为我的事件持久性引擎。

1) 在文档中，ExampleUsage.cs 在“BuildSerializer”中使用了 3 个序列化器。我想这只是为了展示反序列化过程的灵活性？

2) 在“失败后重新启动”的情况下，某些事件没有被调度，我相信我需要调用 GetUndispatchedCommits() 然后调度它们的启动代码，对吗？

3) 同样，在“ExampleUseage.cs”中，如果“TakeSnapshot”将第三个事件添加到事件存储中，然后“LoadFromSnapShotForward”不仅检索最近的快照，还检索到快照后模拟的事件，这将很有用聚合的重建。

4) 我没有看到保留旧快照的用途。你能给出一个有用的用例吗？

5) 如果我有一个服务正在处理命令接收和事件生成，那么建议的策略是跟踪自给定聚合的最后一个快照以来的事件数量。我当然不想太频繁地调用“GetStreamsToSnapshot”。

6) 在 SqlPersistence.SqlDialects 命名空间中，sql 语句名称是“GetStreamsRequiringSnaphots”而不是“GetStreamsRequiringSnapShots”

Answer 1

1) 有一些“基本”序列化程序——例如 Binary、JSON 和 BSON 序列化程序。示例中的另外两个——GZip/Compression 和 Encryption 序列化程序是包装序列化程序，仅用于修改已经序列化为字节流的内容。例如，我只是展示了灵活性。如果您不想加密，则不必加密。事实上，我有一些使用简单 JSON 运行生产的东西，这使得调试非常容易，因为一切都是文本。

2) SynchronousDispatcher 和 AsychronousDispatcher 实现都配置为查询和查找任何未分派的提交。你不应该做任何特别的事情。

3) Greg Young 谈到了他过去是如何将他的快照“内联”到主要事件流中的，但是在高性能系统中出现了许多乐观的并发和竞争条件。因此，他决定将它们“移出乐队”。出于许多相同的原因，我遵循了这个决定。

此外，当您的 SLA 极低时，快照确实是一个性能考虑因素。如果您有一个包含数千个事件的流，并且您的 SLA 不低，那么为什么不采取最小的性能损失，而不是为您的系统增加额外的复杂性。换句话说，快照是“辅助”概念。它们位于 EventStore API 中，但它们是一个可选概念，应针对某些用例加以考虑。

4) 假设您聚合了数千万个事件，并且您想从最近的快照之前运行“假设”场景。从另一个快照前进要便宜得多。快照作为次要概念的真正好处是，如果您想删除较旧的快照，您可以这样做，而且它根本不会影响您的系统。

5) 在 IPersistStreams 的每个实现中都有一个名为 GetStreamsRequiringSnapshots 的方法。您提供 50 的阈值，例如，它查找自上次快照以来具有 50 个或更多事件的所有流。这可以（并且可能应该）与您的正常处理异步完成。

6) “快照”是该词的正确大小写。很像“网站”曾经是“网站”，但由于普遍使用它变成了“网站”。