什么是分布式事务
问题的引出
先看一张图，一个电商平台的架构图。
image
对于用户来说的一个创建订单的过程，背后很可能跨越了多个应用服务。涉及诸如：订单、库存、积分、优惠券等多个微服务模块，而每个模块的数据库可能存在不同节点上，但是其中的任何一个环节都有可能程序运行错误，导致数据的不一致。
image
例如这个支付操作里涉及到的多个数据库。
单一数据库可以简单的使用事务来保证一致性，但是分布式的问题则需要分布式的事务来控制数据的一致性。
分布式事务的产生的原因
数据库分库分表
由于单表的数据量巨大导致的分库分表，则会涉及到多个数据库的一致性问题。
应用SOA化
业务的服务化。多个业务中心有各自的数据库，也会涉及多个数据库的一致性问题
事务的ACID特性
分布式事务本质也是一个事务，则需要满足ACID特性。
原子性（A）
在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。
一致性（C）
事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。
隔离性（I）
隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
持久性（D）
一旦事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。
常见的分布式事务解决方案
两阶段提交--XA提交机制
XA提交机制
XA中大致分为两部分：
事务管理器：作为全局的调度者，负责各个本地资源的提交和回滚
本地资源管理器：往往由数据库实现
XA机制将提交过程两个阶段
prepare
commit
流程：
事务管理模块在prepare服务A的DB事务、服务B的DB事务都成功后。
逐个commit这些DB事务。
DB在prepare返回OK后，如果没有收到来自事务管理模块的commit/rollback请求则会一直保留该分支事务的数据。
出现错误的情况：
若在prepare阶段出现故障，则回滚prepare过的分支事务，从而达到全局事务回滚。
若在commit阶段出现故障，后续仍然可以再次commit那些未成功commit的分支事务，最终达到全局事务提交。
优点缺点
优点：实现简单易懂
缺点：性能不理想，高并发场景下表现不佳
消息事务+最终一致性
image
流程
借助消息队列，在处理业务逻辑的地方，发送消息，业务逻辑处理成功后，提交消息，确保消息是发送成功的。成功后的消息去通知下一步操作的B系统服务，直到全部执行完毕。
出现错误的情况：
通过消息队列投递来进行处理，如果成功，则结束，如果没有成功，则重试，直到成功。
但是注意要做到幂等性控制，因为在系统调用没有达到期望的结果后会重试，不然就会出现重复的问题。
优点缺点
优点：实现和逻辑简单易懂，性能大幅度提升。
缺点：牺牲了一定的一致性，效果是最终一致性的。
三阶段提交--TCC（Try-Confirm-Cancel）机制
image
流程：
事务管理模块是在服务A、服务B执行完毕后即刻提交其参与的DB事务。
如果全局事务决定提交，则逐个调用服务A和服务B的confirm逻辑
如果全局事务决定回滚，则逐个调用服务A和服务B的cancel逻辑。
出现错误的情况：
只需要根据全局事务当前状态，将服务A、服务B相应的confirm/cancel逻辑重新调用即可。
但是，confirm/cancel逻辑可能会被多次调用，因此，需要保证其幂等性。
优点缺点
优点：完全控制粒度
缺点：不同的业务场景所写的代码都不一样，复用性较差。
作者：linxinzhe
链接：https://www.jianshu.com/p/b07ee74a3e21
随时随地看视频
