REST和事务回滚

Question

我有一些不同的RESTful服务，它们托管在使用不同DB的不同服务器上。我有几个RESTful服务，它们在一个事务单元中调用上面的多个这样的服务。如果这些RESTful服务中的任何一个失败，我们最终都会遇到数据一致性问题。有没有一种整洁的架构方式来编排回滚？或者，拥有事务管理器是可行的吗？

作为一个简单的示例，RESTful服务1有一个POST请求，它将thingamajig的项目计数减少1。RESTful服务2发布一个付款。如果服务2失败了，我们如何才能干净地在服务1上实现回滚，而不需要新的RESTful退款服务(如果必须这样做也没问题)。我正在寻找上述问题的架构答案，这符合REST原则。

Answer 1

分布式事务很复杂，需要每个参与系统都支持回滚的概念。对于您的服务，每个服务都必须支持某种形式的回滚。在分布式系统中以synchronous的方式协调这样的事情可能是不实际或不可取的。在这种情况下，您可能希望异步回滚，并且系统最终将在未来的某个时间点达到一致性。显然还有许多其他细节(超时、错误处理、重试等)。

有关最终一致性的更多详细信息，请查看维基百科条目here。

Answer 2

基本上，问题是您需要在缺省情况下不是DB意义上的事务性的环境( HTTP )中使用事务(因为在HTTP中，事务是一个成功的请求-响应周期)。

@leeor response的内容是完全正确的，我想补充的是我是如何从设计网站解决这个问题的。

所以你需要一个单一的端点，可能是/transactions。通过POST方法，您可以添加一个不可变的新事务(包含所有必要的细节)-在创建之后，您只能通过GET方法请求它的数据/状态。可以更新事务状态/数据的只有服务器本身。

在幕后(在事务创建期间)，应该为参与事务的每个资源创建一个快照(稍后可以反转)。那么所有操作的执行都应该开始，并且在任何失败的情况下，所有快照都应该被反转。你没有提到任何技术，所以很难给出合理的建议。您肯定需要的是全面的日志记录。