domain-driven-design - 丢失的事件如何重播？

Question

我正在尝试了解有关 CQRS 和事件溯源(事件存储)的更多信息。

我的理解是在这种情况下通常不使用消息队列/总线 - 消息总线可用于促进微服务之间的通信，但它通常不专门用于 CQRS。但是，我目前看到的方式 - 消息总线将非常有用，可以保证读取模型最终同步，因此最终一致性，例如当托管读取模型数据库的服务器重新联机时。

我知道 CQRS 通常可以接受最终的一致性。我的问题是；读取端如何知道它与写入端不同步？例如，假设每天在 Event Store 中创建了 2,000,000 个事件，另外 1,999,050 个事件也写入读取存储。剩下的 950 个事件没有写入是因为某处的软件错误或因为托管读取模型的服务器离线了几秒钟等。最终一致性在这里如何工作？应用程序如何知道要重放一天结束时丢失的 950 个事件或由于十分钟前的停机时间而丢失的 x 个事件？

在过去一周左右的时间里，我在这里阅读了一些问题，其中讨论了从事件存储中重放的消息，例如这个:CQRS - Event replay for read side ，但是没有人谈论这是如何完成的。我是否需要设置一个每天运行一次的计划任务并重播自计划任务上次成功之日起创建的所有事件？有没有更优雅的方法？

Answer 1

我在我的项目中使用了两种方法，具体取决于需求:

同步，进程中 阅读模型。在事件被持久化之后，在相同的请求生命周期中，在相同的过程中，Readmodels 被提供这些事件。如果 Readmodel 失败(错误或可捕获的错误/异常)，则会记录错误并跳过该 Readmodel，并为下一个 Readmodel 提供事件等。然后跟随 Sagas，这可能会生成生成更多事件的命令并重复循环。

当 Readmodel 失败的影响可以被业务接受时，当 Readmodel 的数据的准备情况比失败的风险更重要时，我会使用这种方法。例如，他们希望数据立即在 UI 中可用。

错误日志应该可以在某些管理面板上轻松访问，以便有人可以查看它，以防客户端报告写入/命令和读取/查询之间的不一致。

如果您的 Readmodels 相互耦合，这也适用，即一个 Readmodel 需要来自另一个规范 Readmodel 的数据。虽然这看起来很糟糕，但事实并非如此，这总是取决于。在某些情况下，您可以用弹性交换更新程序代码/逻辑重复。

异步，在另一个进程中 读取模型更新程序。当我使用 Readmodel 与其他 Readmodels 的完全分离时使用，当 Readmodel 的失败不会使整个读取端崩溃时；或者当 Readmodel 需要另一种语言时，不同于单体应用。基本上这是一个微服务。当 Readmodel 内部发生一些不好的事情时，有必要通知一些权威的更高级别的组件，即通过电子邮件或短信或其他方式通知管理员。

Readmodel 还应该有一个状态面板，其中包含有关它已处理的事件的各种指标，如果有差距，是否有错误或警告；它还应该有一个命令面板，管理员可以在其中随时重建它，最好不要系统停机。

在任何方法中，Readmodels 都应该很容易重建。

How would you choose between a pull approach and a push approach? Would you use a message queue with a push (events)

我更喜欢基于拉的方法，因为:

它不使用另一个有状态的组件，如消息队列，另一个必须管理的东西，它消耗资源并且可以(所以它会)失败

每个 Readmodel 都以它想要的速率消耗事件

每个 Readmodel 都可以随时轻松更改它使用的事件类型

通过从头开始请求所有事件，可以随时轻松地重建每个 Readmodel

事件的顺序与事实来源完全相同，因为您从事实来源中提取

在某些情况下，我会选择消息队列:

即使事件存储不是

，您也需要事件可用

您需要竞争/平行消费者

您不想跟踪您消费的消息；当它们被消耗时，它们会自动从队列中移除