J Oliver EventStore V2.0问题 [英] J Oliver EventStore V2.0 questions

问题描述

我正在使用CQRS进行项目的实现，并打算将J Oliver EventStore V2.0用作事件的持久性引擎。

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）在在文档中，ExampleUsage.cs在 BuildSerializer中使用了3个序列化器。我以为这只是为了显示反序列化过程的灵活性？

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）在失败后重新启动的情况下，未调度某些事件，我相信我需要启动调用GetUndispatchedCommits（）然后分派它们的代码，对吗？

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）同样，在 ExampleUseage.cs中，如果 TakeSnapshot添加了第三个事件，将很有用到事件存储，然后 LoadFromSnapShotForward不仅检索最新快照，还检索快照后的事件，以模拟聚合的重建。

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）我m无法看到保留旧快照的使用。您能给出一个有用的用例吗？

4) I'm failing to see the use of retaining older snapshots. Can you give a use case where they would be useful?

5）如果我有一个处理命令接收和事件生成的服务，建议的策略是跟踪自上次快照以来给定聚合的事件数。我当然不想太频繁地调用 GetStreamsToSnapshot。

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）在SqlPersistence.SqlDialects命名空间中，sql语句名称为 GetStreamsRequiringSnaphots，而不是 GetStreamsRequiringSnapShots

6) In the SqlPersistence.SqlDialects namespace the sql statement name is "GetStreamsRequiringSnaphots" rather than "GetStreamsRequiringSnapShots"

推荐答案

1）有一些基本序列化程序，例如Binary，JSON和BSON序列化程序。该示例中的其他两个-GZip / Compression和Encryption序列化程序包装了序列化程序，仅用于修改已被序列化为字节流的内容。例如，我只是展示灵活性。如果您不想加密，则不必加密。实际上，我有一些运行使用简单JSON的产品的产品，由于所有内容都是文本，因此调试非常容易。

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）SynchronousDispatcher和AsychronousDispatcher实现都配置为查询并找到所有未调度的提交。您不需要做任何特别的事情。

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）谈到了他过去如何将快照与主事件流内联，但是有一个高性能系统中出现的乐观并发和竞争条件的数量。因此，他决定将它们带外移动。我出于许多相同的原因也遵循了这一决定。

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.

此外，当您的SLA极低时，快照实际上是性能方面的考虑因素。如果您的数据流中包含数千个事件，而您的SLA却不低，那为什么不仅仅降低性能，而又不给系统增加额外的复杂性。换句话说，快照是辅助概念。它们在EventStore API中，但是它们是一个可选概念，在某些用例中应予以考虑。

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）让我们假设您有一个总数为数十的数百万个事件，您想从最近的快照开始运行假设场景。从另一个快照开始便宜得多。快照是次要概念，真正的好处是，如果您希望删除较旧的快照，则可以并且完全不会影响系统。

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）是IPersistStreams的每个实现中的一种称为GetStreamsRequiringSnapshots的方法。您提供的阈值为50，例如，它查找自上次快照以来具有50个或更多事件的所有流。可以（可能应该）从您的正常处理中异步完成。

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）快照是该单词的正确大写。就像网站曾经是网站一样，但是由于常用，它变成了网站。

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".

这篇关于J Oliver EventStore V2.0问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！