architecture - CQRS/最终一致性 - 处理读取端更新失败

Question

我对其他人如何处理 CQRS/Event Sourcing 最终一致系统中的 Read Side DB 更新失败很感兴趣。

我有这样一个系统，它可以将事件附加到我的事件存储中，然后由于某种原因无法更新相应的读取端数据库，从而导致状态不一致。

我已阅读 this post还有 this one它真正专注于在事件存储事件之前管理约束的单例/全局聚合。

但是，当更新失败与约束无关(例如临时硬件故障)时，您如何继续？

另一个提到的解决方案是手动干预，但我想我正试图避免这种情况。高级我正在考虑做一些事情，比如触发某种工作以从事件存储重建我的整个读取端数据库，同时暂时挂起和排队通常更新读取端的命令和事件处理程序。

有没有其他人做类似的事情？有没有更好的办法？

谢谢!

Answer 1

But how do you proceed when update failures are not related to constraints (temporary hardware failure for example)?

区分读写模型的部分原因是我们可以异步更新读取模型。
因此，如果您想让读取模型的缓存表示保持热状态，您可以安排读取模型的刷新以定期运行。下一次计划的更新将缓解暂时性故障。没什么大不了。
另一种选择是将读取模型视为缓存；在将结果返回给客户端之前，您首先检查缓存的表示是否仍然有效，然后决定要采取哪种替代方案:向客户端报告查询当前不可用，向客户端报告最新的可用信息，使用注释解释数据陈旧，尝试按需刷新读取模型(采取延迟命中，如果失败，可能需要回退到其他方法之一)。
考虑在查询中明确及时性通常很有用——“我需要一个不到 10 分钟的答案”。然后每个人都在同一页面上讨论可用的表示是否足够好。

how would I avoid not overwriting any read side updates that may come through while I am running the refresh?

思 Conditional PUT ，其中我们使用的条件谓词是当前表示的源数据比当前存储的副本新。
如果您的源数据比之前存储的表示的源数据新，那么您可以替换它。如果您的源数据较旧，那么您就扔掉了工作。因此，您可以存储表示元数据，以便将一个源与另一个源进行比较。