SOA 和分布式事务
分布式事务何时在面向服务的架构中有意义？
When do distributed transactions make sense in a service-oriented architecture?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
分布式事务何时在面向服务的架构中有意义？
When do distributed transactions make sense in a service-oriented architecture?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
分布式事务在 SOA 环境中经常使用。如果您有一个调用多个服务的组合服务，则底层服务调用应作为单个事务处理。业务流程应该允许回滚其步骤。如果底层资源允许，您可以使用两阶段提交，但在许多情况下这是不可能的。在这些情况下，应该对失败步骤之前调用的服务/资源执行补偿操作。换句话说，以相反的顺序撤消成功的步骤。
想象的示例：电信公司为具有 6 个服务呼叫的客户提供新的 VoIP 产品：
上述 6 个步骤应该是一笔交易的一部分。例如，如果库存更新失败，您（可能）需要撤消客户设备配置。
Distributed transactions are used very often in SOA environments. If you've a composite service calling multiple services, the underlying service calls should be handled as a single transaction. Business processes should allow for a roll-back of their steps. If the underlying resources allow for it, you can use 2-phase commits, but in many cases it is impossible. In these cases compensating actions should be done on the services/resources invoked before the failed step. In other words, undo the succeeded steps in a reverse order.
Imaginary example: telecom company provisions a new VoIP product for a customer with 6 service calls:
The 6 steps above should be parts of one transaction. E.g. if inventory update fails, you (may) need to undo the customer equipment configuration.
并不是说它们什么时候有意义。事务（分布式或非分布式）是根据需要而不是任意选择来实现的，以保证一致性。另一种方法是实施协调流程以确保最终的一致性。
在经典的银行示例中（资金从账户 A 转入账户 B），交易一致性非常重要。在某些库存系统（检查库存、减少库存、销售给客户）中，库存水平大致准确（而不是有保证）可能是可以接受的。在这种情况下，忽略失败（减少库存、销售未能完成）可以通过稍后协调来处理。
Not really a case of when they make sense. A transaction (distributed or not) is implemented by necessity rather than arbitrary choice, to guarentee consistency. The alternative is to implement a reconcilliation process to ensure eventual consistency.
In the classic bank example (money out of account A, into account B), transactional consistency is pretty much essential. In some inventory systems (check inventory, decrement inventory, sell to customer), it may be acceptable for stock levels to be roughly accurate, rather than guarenteed. In which case, ignoring a failure (decrement inventory, sale fails to complete) could be dealt with by reconciling later.