分布式设计模式-分布式事务

分布式事务的挑战

在多个服务、数据库和消息代理之间维持数据的一致性的传统方式是采用分布式事务。分布式的事实标注是XA、XA采用了两阶段提交老保证事务中的全部参与方同时完成提交，或者失败时同时回滚。应用程序的整个技术栈须要知足XA标准。

许多新技术，包括NoSQLshujk ,liru MongoDB和Cassandra并不支持XA标准的分布式事务。一样，一些流行的消息代理如RabbitMQ和Apache Kafka也不支持分布式事务。若是你坚持在微服务中使用分布式事务，那么不得不放弃使用这些流行的数据库或消息代理。

saga

将跨越多个服务的每一个业务事务做为一个SAGA实现。SAGA是一系列本地事务。每一个本地事务更新数据库并发布消息或事件以触发SAGA中的下一个本地事务。若是本地事务因为违反业务规则而失败，那么SAGA将执行一系列补偿事务，以撤消前面的本地事务所作的更改。

有两种协调方式：

• 协同-每一个本地事务发布触发其余服务中本地事务的域事件
• 编排-编排器（对象）告诉参与者要执行的本地事务

协同式

编排

saga这种模式有如下好处：

它使应用程序可以跨多个服务维护数据一致性，而无需使用分布式事务 此解决方案有如下缺点：

编程模型更复杂。例如，开发人员必须设计补偿事务，以显式地撤消在SAGA前面所作的更改。 还须要解决如下问题：

为了可靠，服务必须自动更新其数据库并发布消息/事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。相反，它必须使用下面列出的模式之一。