我在看两种情况:A是好的,B不确定。
场景A:模拟应用程序在提交后,在调度前重启
- 开始EventStore
- 提交变化
- 事件未发送
- 停止事件存储
- 启动事件存储
在步骤5中再次发送已提交事件。这工作得很好,我在调度程序代码中也看到了这一点。
场景B:模拟总线错误
- 开始EventStore
- Commit change 1
- 调度程序异常
- Commit change 2
- 分派好
在这种情况下,我找不到行为,也想知道它是否是一个有效的情况:只有在总线代码中存在错误时才会发生这种情况。
是否有触发将重试调度或我需要编写代码来处理这个或我的推理错误?
您对场景A的评估是正确的,在诸如应用程序或机器重新启动/进程终止之类的故障条件下,当进程再次启动时,它将发现未分派的提交并将它们推送给调度程序。
场景B有点棘手。问题是EventStore不是一个总线,所以如何处理总线中的错误的问题并不是不能在EventStore本身中处理的。此外,因为有许多总线实现,所以我不想将EventStore与任何特定的实现耦合。有些用户甚至可能不使用消息总线;他们可能决定使用RPC调用。
那么真正的问题是,应该如何处理总线故障——以及扩展到队列故障?EventStore有一个接口IPublishCommits。当一个事件被提交时,它会被推送到调度程序。调度程序只负责在IPublishCommits的实现正确且成功地处理了事件后,将事件标记为已调度。 处理瞬态总线和队列故障的最佳方法是在IPublishCommits实现中实现断路器模式,该模式会重试,直到事情重新开始工作。对于更大的问题,例如序列化失败,您可能希望记录某种严重的失败,以便立即通知管理员。同样,所有这些棘手的问题是,EventStore无法了解你的情况的所有细节。