我对其他人如何处理 CQRS/事件溯源最终一致系统中的读取端数据库更新失败感兴趣。
我有这样一个系统，它可以将事件附加到我的事件存储中，然后由于某种原因无法更新相应的读取端 DB，从而导致不一致状态。
我已阅读 this post 和 this one，它们真正关注在事件存储事件之前管理约束的单例/全局聚合。
但是，当更新失败与约束无关时（例如临时硬件故障），您将如何处理？
另一个提到的解决方案是人工干预，但我想我想避免这种情况。高级别的我正在考虑做一些事情，比如触发某种工作来从事件存储中重建我的整个读取端数据库，同时暂时挂起和排队通常更新读取端的命令和事件处理程序。
还有其他人做类似的事情吗？有没有更好的办法？
谢谢！
【问题讨论】：
标签： architecture domain-driven-design cqrs event-sourcing eventual-consistency
但是当更新失败与约束无关时（例如临时硬件故障），您如何处理？
区分读取和写入模型的部分原因是我们可以异步更新读取模型。
因此，如果您想保持读取模型的缓存表示处于热状态，您可以安排读取模型的刷新以定期运行。下一次计划更新将缓解暂时性故障。没什么大不了的。
另一种选择是将读取模型视为缓存；在将结果返回给客户端之前，您首先检查缓存的表示是否仍然有效，然后决定您要采用哪种替代方案：向客户端报告查询当前不可用，向客户端报告最新的可用信息，通过注释说明数据已过时，尝试按需刷新读取模型（承受延迟，如果 失败，可能需要回退到其他方法之一）。
考虑在查询中明确及时性通常很有用——“我需要一个不到 10 分钟的答案”。然后每个人都在同一个页面上讨论可用的表示是否足够好。
如何避免在运行刷新时不覆盖任何可能通过的读取端更新？
想想Conditional PUT，我们使用的条件谓词是当前表示的源数据比当前存储的副本更新。
如果您的 source 数据比先前存储的表示的源数据更新，那么您可以替换它。如果您的源数据较旧，那么您将丢弃工作。因此，您可以存储表示元数据，以便您将一个来源与另一个来源进行比较。
【讨论】：