分布式事务的挑战
在多个服务、数据库和消息代理之间维持数据的一致性的传统方式是采用分布式事务。分布式的事实标注是XA、XA采用了两阶段提交老保证事务中的所有参与方同时完成提交，或者失败时同时回滚。应用程序的整个技术栈需要满足XA标准。
许多新技术，包括NoSQLshujk ,liru MongoDB和Cassandra并不支持XA标准的分布式事务。同样，一些流行的消息代理如RabbitMQ和Apache Kafka也不支持分布式事务。如果你坚持在微服务中使用分布式事务，那么不得不放弃使用这些流行的数据库或消息代理。
saga
将跨越多个服务的每个业务事务作为一个SAGA实现。SAGA是一系列本地事务。每个本地事务更新数据库并发布消息或事件以触发SAGA中的下一个本地事务。如果本地事务由于违反业务规则而失败，那么SAGA将执行一系列补偿事务，以撤消前面的本地事务所做的更改。
有两种协调方式：
- 协同-每个本地事务发布触发其他服务中本地事务的域事件
- 编排-编排器（对象）告诉参与者要执行的本地事务
协同式
编排
saga这种模式有以下好处：
它使应用程序能够跨多个服务维护数据一致性，而无需使用分布式事务 此解决方案有以下缺点：
编程模型更复杂。例如，开发人员必须设计补偿事务，以显式地撤消在SAGA前面所做的更改。 还需要解决以下问题：
为了可靠，服务必须自动更新其数据库并发布消息/事件。它不能使用跨越数据库和消息代理的分布式事务的传统机制。相反，它必须使用下面列出的模式之一。
