分布式事务理论以及解决方案

分布式事务理论在分布式框架中一个流程可能会涉及到多个服务此时就需要使用分布式事务来保证这整个流程的事务也就是保证这个流程要么都执行要么都不执行。实际上只要跨数据库的场景都会使用到分布式事务来保证操作的原子性假设某个数据库量太大进行了分库的操作此时数据库的事务已经无法满足需求了就需要使用分布式事务来保证事务。对于事务而言它是有ACID的四个特性的但是分布式事务较为特殊它其实无法完全满足这四个特性往往只能进行折中处理。在分布式事务中有两个经典的理论CAP以及BASE理论。CAPCAP代表的是可用性、一致性以及分区容错性。可用性指的是在分布式架构下我们不论访问哪个节点都需要能够正常访问不能出现阻塞或拒绝的情况而一致性则指的是在分布式的集群架构下当用户访问相同的数据时每个节点锁返回的数据应该都是一致的最后来说分区容错性这个需要拆开来看首先是分区这个指的是当某一个服务有3台实例A、B、C此时由于网络问题导致C与A、B之间断开联系了此时就分为两个区这个情况就叫分区而分区容错则指的是当出现分区的情况下整个系统也要能够正常的为用户提供服务。因此对于CAP这三个特性而言分区容错是一定要保证的否则当出现网络抖动时整个分布式架构直接崩溃这对系统而言是非常灾难的。在保证分区容错的前提下还是刚才A、B、C的例子当用户访问到C机器时此时由于C被孤立出来了无法与A、B两台机器进行通信那么它的数据一定是过时的在这种情况下如果想要保证可用性就只能让C机器返回过期的数据这样就无法保证数据的一致性而如果想保证一致性则只能等A、B与C之间的连接重新建立起来在这个过程中C实际上是不可用的可用性就无法进行保证。上面这段话就回答了这个理论两个比较经典的问题分区容错为什么一定要保证以及在保证分区容错性的前提下一致性与可用性为什么只能保证一个。因此在实际的开发中需要根据业务需求来选择保证CP还是AP。而在实际的开发中当我们选择了AP的方案时就可以使用BASE理论来指导AP方案。BASE接下来说说base理论这个理论其实就是CAP中AP的指导思想帮助我们实现最终一致性的。BASE有基本可用、软状态以及最终一致三要素这三要素并不像CAP一样是取舍的关系而是层层递进的关系。基本可用指的是服务出现故障时允许牺牲部分可用性来保证整体架构的可用性。软状态指的是在整个流程中允许出现中间态也就是在过程中可以出现数据的不一致。最终一致性则指的是虽然在过程中无法保证强一致性但是当软状态结束之后整个数据要达成最终一致的状态。例如一个下单业务中其中涉及到订单服务、账户服务以及库存服务在整个流程中前两个服务都正常执行并提交事务此时对于整个流程而言它们是存在中间态的因为整个流程还没走完此时在执行最后一个服务的时候报错了此时需要对前两个服务进行回滚但是前两个服务执行完毕之后直接将事务提交了此时就只能对前两个事务进行逆向操作来实现回滚的逻辑。总结ACID 是数据库事务完整性的理论CAP 是分布式存储系统的设计理论BASE 是 ACID 在分布式场景中的替代品同时也是 AP 架构的工程实践指南。分布式事务解决方案分布式事务最常见的是使用seata组件解决seata这个组件是阿里出的spring cloud组件专门用于处理分布式事务问题的组件。它包含以下三部分TC事务协调器维护全局事务以及分支事务的状态协调全局事务提交以及回滚TM事务管理器定义全局事务的范围、开启全局事务、提交以及回滚全局事务RM资源管理器在事务中的每一个微服务就是一个RM在seata中有不同的模式不同的模式对应不同的流程。XA模式首先由事务管理器来开启全局事务之后事务管理器调用分支事务让每一个分支事务注册到事务协调器中接下来各个微服务执行自己的业务sql分支事务向事务协调器报告自己的事务状态当事务管理器提交全局事务的时候事务协调器此时检查分支事务所提交的事务状态以此判断分支事务是提交还是回滚进而决定事务协调器是提交还是回滚全局事务这整个流程实际上是实现了CAP思想中的CP思想保证了数据的强一致性因为对于所有的分支事务而言它们只在最后一步才会同时进行提交或回滚这也就意味着当微服务没有执行完时其它已经执行完毕的服务只能等待性能上会有降低AT模式对于这种模式其实它算是XA模式的优化前面的步骤都一样但是到了执行业务sql这一步的时候会有区别AT模式在执行完业务sql之后会直接进行提交之后假设需要回滚直接利用undo log实现对业务sql的回滚即可如果不需要回滚则直接将undo log生成的命令直接删除即可。这种模式的好处就是不再需要像XA模式那样让每个服务之间进行等待每个服务执行完业务sql之后直接提交即可通过引入undo log在保证强一致的情况下还提升的性能通常开发中使用的比较多的就是AT模式也是seata官方推荐的模式TCC模式这个模式主要涉及到三个步骤try、confirm以及cancle。当执行业务sql的时候先执行try操作也就是对要操作的资源进行预留如果此时数据库中有这么多的资源此时就可以进行confirm操作这个操作就是实际的执行业务sql的操作如果执行失败则走到cancle的逻辑对前一步的confirm进行回滚。假设在try操作的时候发现数据库中没有这么多资源此时就会直接对资源进行解冻。这个模式的流程其实性能相较于XA模式也是较高的但是它的三个步骤都需要我们手动编码实现代码耦合度太高了而前面两个模式都是组件帮助我们进行实现。MQ