我试图弄清楚我的事件存储和我的读取模型在实际具体实现方面是如何相关的。
我对事件存储的有限了解使我相信:
- 事件提交给事件存储
- 调度员运行
- 如果我使用队列，我会将消息发送到队列(比方说公共(public)交通)
- 我的读模型订阅了队列，所以我的读数据库得到了消息(mysql)
- 我的阅读模型随着我的数据的新变化而更新
这意味着如果公共(public)交通出现任何问题，我的读取数据库将不同步，我必须想办法将其同步回来。
我读过/看过 greg young 发表的一些内容建议使用事件存储本身作为队列，并通过在事件存储端保留一个自动递增数字来保持一致性，以保持最终一致性。我想知道这是否已在 joliver 的项目中实现？
最佳答案
so my read database gets the message (mysql)
我要重申，“我的事件处理器为给定的事件获取消息并且(在我的例子中)通常会在 mysql 数据库中操作状态”(或者你的意思是别的？)。
This would mean that if anything happened to mass transit, my read database will be out of sync and I have to figure out how to sync it back.
是的，您的队列成为您应用状态的一部分，它需要备份和恢复。请注意，Dispatcher 在成功将 Commit 放入 Queue 之前不会标记 Commit dispatched，并且在您确认完成处理以进行必要的更新以同步状态之前，排队系统不会删除消息阅读模型。
请记住，您可以将多个 Web 服务调用视为处理事件的必要工作的一部分。
另一件要记住的事情是，您需要让您的事件处理器是幂等的(即能够处理至少一次传送)。
更进一步，如果事件无法完成处理，您将很高兴地考虑您将要做什么 - 您是否要对消息进行死信处理？谁来监控？
顺便说一句，根据您的托管安排，Azure(或本地 Windows)ServiceBus 可能值得考虑)
Some stuff I've read/watched that's been published by greg young suggest using the event store itself as a queue, and maintain consistency by keeping an auto increment number on the event store side in order to maintain eventual consistency. I'm wondering if that is implemented in joliver's project?
不，JOES 为您提供了一个 Dispatcher Hook ，然后您可以决定什么是适合您的。这是好是坏。有些系统根本没有绑定(bind)到有状态读取模型的 Dispatcher - 它们只是查询事件存储中的事件并构建内存中读取模型以短路所有这些。
不确定您所说的自动递增数字是什么意思。
请注意 GES 中的投影内容还没有完全 1.0(但不言而喻，它非常值得您认真考虑 - 它本质上处理了您在这些问题中涉及的大部分问题)
关于c# - joliver/EventStore 最终一致性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15254684/