在微服务架构下，每个服务对应一个数据库，这就出现了原来单体中对同一个库的操作变成了跨服务数据库的操作。
遇到有事务约束的场景，比如转账汇款、订单状态和库存扣减，就从本地事务过渡到分布式事务来了。
微服务利用最终一致性解决这个问题
最终一致性：不同服务节点再一段时间后，节点间的数据会最终达到一致的状态
有两种方法可以完成最终一致性 ：
1.可靠性时间模式
前序事件发生，后序事件一定发生。可靠性事件的缺点是不能回滚。一般借助消息队列和内部表来完成。
支付宝余额转账到余额宝余额为例：
当发起一个请求到支付宝服务的时候，支付宝会执行扣款事件，并将这个事件记录下来，并且发送消息到余额宝服务，之后余额宝执行加款事件并将该消息投递到支付宝服务，支付宝服务得到该条消息后删除事件记录。如果余额宝服务出现故障，支付宝服务一直没有接受到回送的消息，定时任务会检测该事件一直存在数据库当中，并一直发送消息给余额宝直到余额宝服务恢复加款后回送消息支付宝给删除记录。
2.补偿事务-sagsas模型
sag是一系列有序本地事务，每个本地事务通过更新数据库或者发送消息来触发下一个本地事务。
每一个本地事务都会发送消息并确认消息，如果本地事务失败，sag会有序的执行补偿事务来回滚刚才的操作。它的特点就是支持回滚。
每一个事务都有发送消息和接收确认消息的操作
该方案比较复杂，目前还没有开源框架来支持。