我对其他人如何处理CQRS / Event Sourcing最终一致的系统中的Read Side DB更新失败很感兴趣。
我有这样一个系统，可以将事件追加到事件存储中，然后由于某种原因而无法更新相应的读取侧DB，从而导致出现不一致状态。
我已经读过this post和this one，它们的重点是具有一个单例/全局集合，该集合在事件存储事件之前管理约束。
但是，如果更新失败与约束条件无关（例如临时性硬件故障），您将如何进行？
另一个提到的解决方案是手动干预，但我想我正在努力避免这种情况。高级别，我正在考虑执行一些操作，例如触发某种工作以从事件存储区重建我的整个读取侧数据库，同时暂时挂起和排队通常会更新读取侧的命令和事件处理程序。
其他人会做与此类似的事情吗？有更好的方法吗？
谢谢！
答案 0 :(得分：0)
但是，如果更新失败与约束条件无关（例如临时性硬件故障），您将如何进行？
区分读写模型的部分目的是我们可以异步更新读写模型。
因此，如果要保持读取模型的缓存表示很热，可以安排刷新读取模型，使其以一定的间隔运行。下一次计划的更新将缓解暂时性故障。没什么。
另一种选择是将读取模型视为高速缓存；在将结果返回给客户端之前，您首先要检查缓存的表示形式是否仍然有效，然后确定要采用的替代方法：向客户端报告查询当前不可用，向客户端报告最新的可用信息，带有说明数据过时的注释，请尝试按需刷新读取的模型（造成延迟，如果 失败，则可能需要回退到其他方法之一）。
考虑在查询中明确及时性通常很有用-“我需要10分钟以内的答案”。然后每个人都在同一页面上，关于可用表示是否足够好。
如何避免不覆盖运行刷新时可能发生的任何读取方面的更新？
考虑Conditional PUT，我们使用的条件谓词是当前表示的源数据比当前存储的副本新。
如果您的 source 数据比以前存储的表示形式的源数据新，则可以替换它。如果您的源数据较旧，那么您就放弃了工作。因此，您可以与制图表达元数据一起存储，以使您可以将一个来源与另一个来源进行比较。