我的系统由几个组件组成，一个请求通常遍历所有组件，每个组件使用自己的DB表来跟踪系统状态。
例如，当请求到达时，组件A通过以下方式创建资源R： 1.为R创建DB行，将状态标记为“正在创建” 2.应用层执行可能需要几分钟或几小时的实际工作。 3.更新R的DB行，将状态标记为“Ready”
每个组件都做类似的事情。
问题是，系统可能随时崩溃并使系统处于中间状态。例如，资源R可能在系统故障后保留在“正在创建”中。
我的问题是，对于这样的系统，它不能使用事务来覆盖所有步骤（事务太长或系统是分布式的），恢复系统的设计模式或最佳实践是什么？
我认为这种情况在ERP系统或使用SOA的任何系统中都很常见。
更新 请求可以重新发送，但处于中间状态“Creating”的资源R可能是在现实世界中创建的，这在某种程度上就像在分布式系统中一样，组件崩溃导致整个系统状态不一致。设计一个可以在失败后重新同步系统的系统有什么做法？
答案 0 :(得分：1)
您可以将请求作为JMS消息路由到系统的组件上。这样，您可以将消息持久性和传递保证的任务委派给JMS实现（例如，Active MQ）。如果某个组件崩溃，该邮件将被重新传递给它。
根据OP的评论添加以下部分。
更新：请求可以重新发送，但资源R处于中间状态＆＃39;创建＆＃39;这可能是在现实世界中创建的，这在某种程度上就像在分布式系统中一样，组件崩溃导致整个系统状态不一致。设计一个可以在失败后重新同步系统的系统有哪些实践？
这高度依赖于所讨论的系统及其组件的性质，这是实现抗故障系统的一种方法。
1）组件之间的消息不应丢失，应保证其交付。这可以通过专用的消息队列来完成。
2）每个操作应该是idempotent，可以多次调用而不会产生任何额外的副作用。这样，如果在消息处理期间发生错误，则消息队列将再次发送消息，并且组件将处理该消息，例如。检查其完成状态是否符合其本地状态，并仅执行必要的步骤以完成操作，跳过已完成的操作。
有关更完整的答案和系统设计指南，请查看WS-BPEL