未来架构| 云原生时代的分布式事务

导读：微服务拆分之后，在很多场景，分布式事务无法避免。而分布式事务是行业内的一个技术难点，没有一种完美的方案。分布式事务有哪些解决方案？又应该如何落地？听京东数科数据研发负责人张亮讲述分布式事务的点点滴滴。本文适合研发工程师，技术经理，架构师反复阅读。
前文提到过，数据库事务是需要满足ACID（原子性、一致性、隔离性、持久性）四个特性的。

在单一数据节点中，事务仅限于对单一数据库资源进行访问控制，这种事务称为本地事务。几乎所有成熟的关系型数据库都提供了对本地事务的原生支持。但是在基于微服务的分布式应用环境下，越来越多的应用场景要求将多个服务的访问以及相对应的数据库资源纳入同一个事务，因此，分布式事务应运而生。

关系型数据库虽然对本地事务提供了完美的ACID原生支持。但在分布式的场景下，它却成为了系统性能的瓶颈。如何让数据库在分布式场景下满足ACID特性，或找寻相应的替代方案，是分布式事务的重点工作内容。

• XA协议

最早的分布式事务模型是由 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing（DTP）模型，也称为XA协议。

XA协议通过一个全局事务管理器与多个资源管理器进行交互。全局事务管理器负责管理全局事务状态和参与事务的资源，资源管理器则负责具体的资源操作，XA协议与应用程序的关系如图9-9所示。

XA协议使用两阶段提交来保证分布式事务的原子性以，它将提交过程分为准备阶段和提交/回滚阶段。两阶段提交也是XA协议的标准实现。

在准备阶段，全局事务管理器向每个资源管理器发送准备消息，用于确认本地事务操作成功与否。在提交阶段，若全局事务管理器收到了所有资源管理器回复的成功消息，则向每个资源管理器发送提交消息，否则发送回滚消息。资源管理器根据接收到的消息对本地事务进行提交或回滚。图9-10展示了XA协议的事务流程。

开启XA全局事务后，所有子事务会按照本地默认的隔离级别锁定资源，并记录undo和redo日志，然后由TM发起prepare投票，询问所有子事务是否可以进行提交。当所有子事务反馈的结果为“yes”时，TM再发起commit；若其中任何一个子事务反馈的结果为“no”，TM则发起rollback；如果在prepare阶段的反馈结果为yes，而commit的过程中出现宕机等异常，则在节点服务重启后，可根据XA recover再次进行commit补偿，以保证数据的一致性。

基于XA协议实现的分布式事务对业务的侵入性很弱。它最大