分布式事务在SOA环境中经常使用。如果你有一个复合服务调用多个服务,那么底层服务调用应该被处理为单个事务。业务流程应该允许撤销其步骤。如果底层资源允许,可以使用2PC提交,但在许多情况下这是不可能的。在这些情况下,在执行失败的步骤之前应对所调用的服务/资源进行补偿操作。换句话说,以相反的顺序撤销已成功的步骤。 虚构例子:电信公司为客户提供新的VoIP产品,其中包括6个服务调用: 查询库存以检查客户是否具备正确的设备 通过调解配置客户设备 更新库存以进行新配置 设置评级引擎以计算客户的CDR 设置计费软件以按照正确的价格计划向客户收费 使用预配过程结果更新CRM系统 上述6个步骤应该是一个事务的一部分。例如,如果库存更新失败,则需要(可能)撤销客户设备配置。
这并不是说它们何时有意义的问题。事务(分布式或非分布式)的实现是出于必要性而非任意选择,以保证一致性。另一种选择是实现一个调和过程来确保最终一致性。 在经典的银行示例中(从账户A中取出钱,存入账户B),事务一致性几乎是必不可少的。在某些库存系统中(检查库存、减少库存、销售给客户),库存水平大致准确而非保证可能是可以接受的。在这种情况下,忽略失败(减少库存,销售未能完成)可以通过稍后调和来处理。