我试图弄清楚我的事件存储和我的读取模型在实际的螺母和螺栓实现方面是如何相关的。
我对事件存储的有限理解使我相信:
- 事件提交到事件存储
- 调度程序运行
- 如果我使用队列，我将消息发送到队列(比如公共交通)
- 我的读模型被订阅到队列，所以我的读数据库得到消息(mysql)
- 我的读取模型随着我的数据的新变化而更新
这就意味着，如果公共交通系统出了什么问题，我的读数据库就会不同步，我必须想办法把它同步回来。
我读过/看过greg young发表的一些文章，建议使用事件存储本身作为队列，并通过在事件存储端保持一个自动递增的数字来保持一致性，以保持最终的一致性。我想知道这是否在joliver的项目中实现了?
所以我的读数据库得到消息(mysql)
我将重新声明为"我的事件处理器(s)为给定的事件获取消息，(在我的情况下)通常会在mysql数据库中操作状态"(或者你是指别的什么?)。
这就意味着，如果公共交通系统出了什么问题，我的读数据库就会不同步，我必须想办法把它同步回来。
是的，你的队列成为你的应用状态的一部分，它需要备份和弹性。请注意，Dispatcher在成功地将Commit放到Queue上之前不会将其标记为已调度，并且队列系统不会删除该消息，直到您确认完成处理以进行必要的更新以同步Read Model中的状态。
请记住，您可以将多个web服务调用都视为处理事件所需工作的一部分。
另一件要记住的事情是，你会希望你的事件处理器是幂等的(即能够处理至少一次交付)。
再往下看，如果事件不能完成处理，你会很高兴地考虑你要做什么——你要死信这个消息吗?谁来监督呢?
顺便说一句，根据您的托管安排，Azure(或本地Windows) ServiceBus可能值得考虑)
我读过/看过greg young发表的一些文章，建议使用事件存储本身作为队列，并通过在事件存储端保持一个自动递增的数字来保持一致性，以保持最终的一致性。我想知道这是否在joliver的项目中实现了?
不，JOES为您提供了Dispatcher钩子，然后您决定什么适合您。这是好事也是坏事。有些系统根本没有将Dispatcher绑定到有状态读取模型—它们只是查询事件存储并构建内存中的读取模型来缩短所有这些。
我不知道你说的自动递增数字是什么意思。
请注意，GES中的投影功能还没有完全实现1.0(但不用说，它非常值得您的强烈考虑-它本质上处理了您对这些问题所涉及的大部分关注)