分布式事务的七种解决方案.pdfVIP

分布式事务的七种解决⽅案 随着业务的快速发展、业务复杂度越来越⾼，⼏乎每个公司的系统都会从单体⾛向分布式，特别是转向微服务架构。随之⽽来就必然遇到分 布式事务这个难题。 这篇⽂章⾸先介绍了相关的基础理论，然后总结了最经典的事务⽅案，最后给出了⼦事务乱序执⾏（幂等、空补偿、悬挂问题）的解决⽅ 案，分享给⼤家。 基础理论 在讲解具体⽅案之前，我们先了解⼀下分布式事务所涉及到的基础理论知识。 我们拿转账作为例⼦，A需要转100元给B，那么需要给A的余额-100元，给B的余额+100元，整个转账要保证，A-100和B+100同时成 功，或者同时失败。看看在各种场景下，是如何解决这个问题的。 事务 把多条语句作为⼀个整体进⾏操作的功能，被称为数据库事务。数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失 败。 事务具有 4 个属性：原⼦性、⼀致性、隔离性、持久性。这四个属性通常称为 ACID 特性。 Atomicity（原⼦性） ：⼀个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执⾏过程中发⽣ 错误，会被恢复到事务开始前的状态，就像这个事务从来没有执⾏过⼀样。 Consistency（⼀致性） ：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应⽤定义的等约束不 会被破坏。 Isolation（隔离性） ：数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒，隔离性可以防⽌多个事务并发执⾏时由于交叉执 ⾏⽽导致数据的不⼀致。 Durability（持久性） ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 假如我们的业务系统不复杂，可以在⼀个数据库、⼀个服务内对数据进⾏修改，完成转账，那么，我们可以利⽤数据库事务，保证转账业务 的正确完成。 分布式事务 银 ⾏跨 ⾏转账业务是⼀个典 型分布式事务 场景 ，假设 A需要 跨 ⾏转账给B，那么就涉及 两 个银 ⾏的 数据 ，⽆法通过 ⼀个 数据库 的 证 转账的ACID， 只能够通过分布式事务来解决。 分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。在上述转账的业务中，⽤户A-100 操作和⽤户B+100操作不是位于同⼀个节点上。本质上来说，分布式事务就是为了保证在分布式场景下，数据操作的正确执⾏。 分布式事务在分布式环境下，为了满⾜可⽤性、性能与降级服务的需要，降低⼀致性与隔离性的要求，⼀⽅⾯遵循 BASE 理论（BASE相关 理论，涉及内容⾮常多，感兴趣的同学，可以参考BASE理论）： 基本业务可⽤性 （Basic Availability） 柔性状态 （Soft state） 最终⼀致性 （Eventual consistency） 同样的，分布式事务也部分遵循 ACID 规范： 原⼦性：严格遵循 ⼀致性：事务完成后的⼀致性严格遵循；事务中的⼀致性可适当放宽 隔离性：并⾏事务间不可影响；事务中间结果可见性允许安全放宽 持久性：严格遵循 分布式事务的解决⽅案 由于分布式事务⽅案，⽆法做到完全的ACID的保证，没有⼀种完美的⽅案，能够解决掉所有业务问题。因此在实际应⽤中，会根据业务的 不同特性，选择最适合的分布式事务⽅案。 两阶段提交/XA XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接⼝。本地的数 据库如mysql在XA中扮演的是RM⾓⾊ XA⼀共分为两阶段： 第⼀阶段（prepare）：即所有的参与者RM准备执⾏事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。 第⼆阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。 ⽬前主流的数据库基本都⽀持XA事务，包括mysql、oracle、sqlserver、postgre XA 事务由⼀个或多个资源管理器（RM）、⼀个事务管理器（TM）和⼀个应⽤程序 （ApplicationProgram）组成。 这⾥的RM、TM、AP三个⾓⾊是经典的⾓⾊划分，会贯穿后续Saga、Tcc等事务模式。 把上⾯的转账作为例⼦，⼀个成功完成的XA事务时序图如下 ： 如果有任何⼀个参与者prepare失败，那么TM会通知所有完成prepare的参与者进⾏回滚。 XA事务的特点是： 简单易理解