崩溃后从中间状态恢复系统的设计模式

Question

我的系统由两个组件组成，一个请求通常会遍历所有组件，每个组件都使用自己的DB表来跟踪系统状态。

例如，当请求到达时，组件A通过以下方式创建资源R : 1.为R创建DB行，将状态标记为“create”2。应用程序层执行可能需要几分钟或几个小时的实际工作。3.为R更新DB行，将状态标记为“就绪”

每个组件都做类似的事情。

问题是，系统可能随时崩溃，并使系统处于中间状态。例如，资源R可能保留在系统故障后的“创建”中。

我的问题是，对于这样一个不能使用事务覆盖所有步骤的系统(要么事务太长，要么系统是分布式的)，恢复系统的设计模式或最佳实践是什么？

我认为这种情况在ERP系统或任何使用SOA的系统中都很常见。

更新：请求可能会引起不满，但是处于中间状态的资源R可能是在现实世界中创建的，这在某种程度上就像在分布式系统中，组件崩溃会导致整个系统状态不一致。设计一个在失败后可以重新生成系统的系统有哪些实践？

Answer 1

您可以通过系统组件将请求路由为JMS消息。这样，您就可以将消息持久性和传递保证的任务委托给JMS实现(例如。(活动MQ)。如果组件崩溃，该消息将被重新传递给它。

下面的部分是在OP的注释中添加的。

更新:请求可能会引起不满，但是处于中间状态的资源R可能是在现实世界中创建的，这在某种程度上就像在分布式系统中，组件崩溃会导致整个系统状态不一致。设计一个在失败后可以重新生成系统的系统有哪些实践？

这在很大程度上取决于所讨论的系统及其组件的性质，这里是实现抗故障系统的一种方法。

1)不应丢失组件之间的消息，并应保证其传递。这可以通过一个专用的消息队列来实现。

2)每次手术均应是幂等，可多次调用，无任何附加副作用。这样，如果在消息处理过程中发生错误，消息队列将再次发送消息，组件将处理消息，例如。对照其本地状态检查其完成状态，只执行完成操作的必要步骤，跳过已经完成的操作。

要获得更完整的答案和系统设计指南，请查看WS-BPEL