如何托管Event Sourcing事件处理程序来构建读取模型？

作者: NetworkAttachedStorage
发布时间: 2024-01-15 09:05:24 (5月前)
转自：

3 条回复

0#
回复此人
求赞有赞必回 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在我们的项目中，我们使用基于订阅的预测。原因是： </p> <UL> <LI> 承诺写入方必须是事务性的，如果您使用两个基础结构（事件存储和消息总线），则必须开始使用DTC，否则您可能会将事件保存到存储但不会发布到总线，或者相反，取决于您的实施。 DTC和两阶段提交是令人讨厌的事情，你不想这样做 </LI> <LI> 事件通常在消息总线中发布（我们也通过订阅来发布），用于不同有界上下文之间的事件驱动通信。如果您使用消息订阅者更新您的读取模型，当您决定重建读取模型时，您的其他订阅者也将获得这些消息，这将使系统处于无效状态。我想你已经考虑过这个问题，因为你说每个发布的消息类型只能有一个订阅者。 </LI> <LI> 消息总线消费者无法保证消息顺序，这可能会使您的读取模型变得混乱。 </LI> <LI> 消息使用者通常通过将消息发送回队列（通常在队列末尾）进行重试来处理重试。这意味着您的活动可能会严重失灵。此外，通常在经过一些重试之后，消息使用者放弃有害消息并将其放入某些DLQ。如果这是您的预测，这将意味着将忽略一个更新，而其他更新将被处理。这意味着您的读取模型将处于不一致（无效）状态。 </LI> </UL> <P> 考虑到这些原因，我们有基于订阅的单线程投影，可以做任何事情。您可以使用自己的检查点执行不同类型的投影，使用追赶订阅订阅事件存储。为了简单起见，我们将它们与许多其他东西一样托管在同一个进程中，但这个过程只能在一台机器上运行。如果我们想要横向扩展这个过程，我们将不得不接受订阅/预测。它可以很容易地完成，因为除了读取模型DTO本身之外，这部分几乎没有其他模块的依赖性，无论如何它都可以作为程序集共享。 </p> <P> 通过使用订阅，您始终可以预测已提交的事件。如果投影出现问题，写入方面肯定是事实的来源并且仍然如此，您只需要修复投影并再次运行它。 </p> <P> 我们有两个独立的 - 一个用于投影到读模型，另一个用于将事件发布到消息总线。事实证明，这种结构非常有效。 </p> </DIV>

编辑
1#
回复此人
疯子哥哥 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 特别是对于EventStore，他们现在有 <a href="http://docs.geteventstore.com/introduction/3.9.0/competing-consumers/" rel="nofollow noreferrer"> 竞争消费者 </A> ，这是基于服务器的订阅，其中许多客户端可以订阅订阅组，但只有一个客户端获取该消息。 </p> <P> 这听起来就像你所追求的那样，服务器场中的每个节点都可以订阅订阅组，接收消息的节点可以进行投影 </p> </DIV>

编辑

登录后才能参与评论