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