J Oliver EventStore V2.0 问题
我正在着手使用 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”
I am embarking upon an implementation of a project using CQRS and intend to use the J Oliver EventStore V2.0 as my persistence engine for events.
1) In the documentation, ExampleUsage.cs uses 3 serializers in "BuildSerializer". I presume this is just to show the flexibility of the deserialization process?
2) In the "Restart after failure" case where some events were not dispatched I believe I need startup code that invokes GetUndispatchedCommits() and then dispatch them, correct?
3) Again, in "ExampleUseage.cs" it would be useful if "TakeSnapshot" added the third event to the eventstore and then "LoadFromSnapShotForward" not only retrieve the most recent snapshot but also retrieved events that were post snapshot to simulate the rebuild of an aggregate.
4) I'm failing to see the use of retaining older snapshots. Can you give a use case where they would be useful?
5) If I have a service that is handling receipt of commands and generation of events what is a suggested strategy for keeping track of the number of events since the last snapshot for a given aggregate. I certainly don't want to invoke "GetStreamsToSnapshot" too often.
6) In the SqlPersistence.SqlDialects namespace the sql statement name is "GetStreamsRequiringSnaphots" rather than "GetStreamsRequiringSnapShots"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
1) 有一些“基本”序列化器——例如 Binary、JSON 和 BSON 序列化器。示例中的另外两个——GZip/压缩和加密序列化器是包装序列化器，仅用于修改已序列化为字节流的内容。举个例子，我只是展示灵活性。如果您不愿意，则不必加密。事实上，我已经使用简单的 JSON 来运行生产，这使得调试变得非常容易，因为一切都是文本。
2) SynchronousDispatcher 和 AsychronousDispatcher 实现都配置为查询和查找任何未分派的提交。你不应该做任何特别的事情。
3) Greg Young 谈到了他过去如何将快照与主要事件流“内联”，但高性能系统中出现了许多乐观的并发和竞争条件。因此，他决定将它们“移出乐队”。出于许多相同的原因，我也遵循了这个决定。
此外，当您的 SLA 极低时，快照实际上是一个性能考虑因素。如果您的流上有几千个事件，并且您的 SLA 不低，那么为什么不只采取最小的性能损失，而不是增加系统的额外复杂性。换句话说，快照是“辅助”概念。它们位于 EventStore API 中，但它们是一个可选概念，应在某些用例中考虑。
4) 假设您有数千万个事件的聚合，并且您希望在最近的快照之前运行“假设”场景。从另一个快照开始要便宜得多。快照作为次要概念的真正好处是，如果您想删除旧快照，您可以这样做，而且它根本不会影响您的系统。
5) IPersistStreams 的每个实现中都有一个称为 GetStreamsRequiringSnapshots 的方法。例如，您提供阈值 50，它会查找自上次快照以来具有 50 个或更多事件的所有流。这可以（并且可能应该）与正常处理异步完成。
6) “Snapshots”是该词的正确大小写。就像“网站”曾经是“网站”一样，但由于常用，它变成了“网站”。
1) There are a few "base" serializers--such as the Binary, JSON, and BSON serializers. The other two in the example--GZip/Compression and Encryption serializers are wrapping serializers and are only meant to modify what's already been serialized into a byte stream. For the example, I'm just showing flexibility. You don't have to encrypt if you don't want to. In fact, I've got stuff running production that uses simple JSON which makes debugging very easy because everything is text.
2) The SynchronousDispatcher and AsychronousDispatcher implementations are both configured to query and find any undispatched commits. You shouldn't have to do anything special.
3) Greg Young talked about how he used to "inline" his snapshots with the main event stream, but there were a number of optimistic concurrency and race conditions in high-performance systems that came up. He therefore decided to move them "out of band". I have followed this decision for many of the same reasons.
In addition snapshots are really a performance consideration when you have extrememly low SLAs. If you have a stream with a few thousand events on it and you don't have low SLAs, why not just take the minimal performance hit instead of adding additional complexity into your system. In other words, snapshots are "ancillary" concepts. They're in the EventStore API, but they're an optional concept that should be considered for certain use cases.
4) Let's suppose you had an aggregate with tens of millions of events and you wanted to run a "what if" scenario from before your most recent snapshot. It's a lot cheaper to go from another snapshot forward. The really nice thing about snapshots being a secondary concept is that if you wanted to drop older snapshots you could and it wouldn't affect your system at all.
5) There is a method in each implementation of IPersistStreams called GetStreamsRequiringSnapshots. You provide a threshold of 50, for example which finds all streams having 50 or more events since their last snapshot. This can (and probably should) be done asynchronously from your normal processing.
6) "Snapshots" is the correct casing for that word. Much like "website" used to be "Web site" but because of common usage it became "website".