事件溯源和 sagas - 补偿交易答案

【问题标题】：Event-sourcing and sagas - compensating transactions事件溯源和 sagas - 补偿交易
【发布时间】：2015-12-21 19:00:55
【问题描述】：

关于 SO 的第一个问题（真的？？？），请多多包涵 :)

我们正在使用事件溯源构建解决方案。我们的一些业务流程将长期运行，因此我们计划使用 sagas 将命令编排到 几个聚合根。

据我了解，如果 saga 发出的命令失败，saga 将负责向所有先前调用的聚合根发出补偿命令。

如果聚合根的状态在外部（即由其他进程/用户）在参与saga，但在 saga 失败并向该聚合根发出补偿命令？

换句话说，如何尝试补偿某个聚合根的事件流中的不是最后一个事件（用 EventStore 术语来说）？

【问题讨论】：

【解决方案1】：

这是一个相当棘手的情况，因为我所看到的是您可能会在您的补偿条目之后得到一个无效的 AR，从而使您的补偿操作无效。

您可能必须重新审视流程的设计，以便在您确定流程经理 (saga) 能够完成之前不对 AR 进行更改。也许暂时存储这些值以供以后更改。

另一种方法可能是阻止 AR 上的某些命令，如果它处于某种状态，表明它可能会导致这些命令出现问题。然后用户将无法发出这些命令。您的流程经理会处理那个状态以及任何状态到期/超时等等。

【讨论】：

感谢您的回答。不过我有一些cmets。您提出的第一个解决方案看起来很像锁定，这可能会导致性能问题。第二个提议假设 AR 将不知道他们参与 saga，在我看来，这违反了 saga 原则，即只有 saga 知道编排细节，而 AR 只是被调用。
我不认为存储值以供以后使用很像锁定:) 第二个选项可能只需要让 saga 工作，但如果它是麻烦然后可能需要另一种解决方案。我之前在流程管理器中使用了相当多的数据，其中状态仅特定于流程管理器。但正如我前面提到的，这是一个棘手的情况。最好的办法是在您确定可以安全应用更改之前避开您的实时 AR。
我一直在考虑这个问题，但我不知道在 AR 上使用某些“状态”是否会使其了解流程管理器。以Order为例，它的生命周期当然有一定的地位，但它与业务流程有关。因此不一定与流程管理器相关，但它肯定知道某种形式的业务流程。
抱歉，从一开始就没有得到答案的第一部分 - 确保存储一些临时数据不会阻塞，我的错。我同意你的观点，即只在安全的情况下存储更改，但在 AR 中包含与 saga 相关的状态将违背 AR 本身与 saga 无关的方面。此外，AR 可以在不同的上下文中参与多个 sagas。一般问题仍然存在 - 在并发环境中工作时，是否有任何模式可以让分布式事务不涉及事务本身？