我试图弄清楚我的事件存储和我的读取模型在实际的具体实现方面是如何相关的。
我对事件存储的有限了解使我相信：
这意味着如果公共交通发生任何事情，我的读取数据库将不同步，我必须弄清楚如何将其同步回来。
我读过/看过的一些由 greg Young 发表的东西建议使用事件存储本身作为队列，并通过在事件存储端保持一个自动增量编号来保持一致性，以保持最终的一致性。我想知道这是否在joliver的项目中实施？
所以我的读取数据库得到消息（mysql）
我会重新声明，“我的事件处理器为给定事件获取消息，并且（在我的情况下）通常会操纵 mysql 数据库中的状态”（或者你的意思是别的吗？）。
这意味着如果公共交通发生任何事情，我的读取数据库将不同步，我必须弄清楚如何将其同步回来。
是的，您的队列成为应用程序状态的一部分，需要备份和恢复。请注意，Dispatcher 在成功将其放入队列之前不会将提交标记为已调度，并且排队系统不会删除消息，直到您确认处理完成以进行必要的更新以同步您的状态阅读模型。
请记住，您可以将多个 Web 服务调用视为处理事件的必要工作的一部分。
要记住的另一件事是，您将希望您的事件处理器是幂等的（即能够处理至少一次交付）。
再往下看，如果事件无法完成处理，你会很高兴考虑你将要做什么——你会死信消息吗？谁来监控它？
顺便说一句，根据您的托管安排，Azure（或本地 Windows）ServiceBus 可能值得考虑）
我读过/看过的一些由 greg Young 发表的东西建议使用事件存储本身作为队列，并通过在事件存储端保持一个自动增量编号来保持一致性，以保持最终的一致性。我想知道这是否在joliver的项目中实施？
不，JOES 为您提供了一个 Dispatcher 钩子，然后您决定什么是适合您的。这有好有坏。有些系统根本没有将 Dispatcher 绑定到有状态的读取模型——它们只是在事件存储中查询事件并构建内存中的读取模型来短路所有这些。
不知道你所说的自动递增数字是什么意思。
请注意，GES 中的 Projection 内容尚未完全 1.0（但不用说，它非常值得您认真考虑 - 它本质上解决了您在这些问题上遇到的大部分问题）