【分布式】java实现分布式事务的五种方案_网站优化分享

您的位置：上海毫米网络优化公司 > 网站优化分享 >

文章目录

背景
什么是分布式事务
- 什么是分布式系统：
- 什么是事务：
- 什么是本地事务：
- 什么是分布式事务：
- 分布式事务有哪些应用场景：
- 如何进行分布式事务控制
- - CAP理论
  - 分布式系统如何兼顾CAP？
  - CAP有哪些组合方式？
  - BASE 理论
  - - 小结
    - 分布式事务一致性解决方案
    - - 两阶段提交协议(2PC)
      - 2PC协议流程图
        应用实例
        2PC的优缺点
        XA 方案
        执行流程如下：
        DTP 模型定义如下角色：
        以上三个角色之间的交互方式如下：
        小结
        XA方案的问题
        事务补偿 TCC
        含义如下
        应用实例
        TCC优缺点
        可靠消息队列实现最终一致性
        优缺点
        分布式事务解决方案之最大努力通知
        什么是最大努力通知
        最大努力通知与可靠消息一致性有什么不同？
        解决方案思想不同
        两者的业务应用场景不同
        技术解决方向不同
        解决方案
        方案1和方案2的不同点：
        小结
        分布式事务对比分析
        总结
        背景
        
        用户支付完成会将支付状态及订单状态保存在订单数据库中，由订单服务去维护订单数据库。由库存服务去维护库存数据库的信息。下图是系统结构图：
        如何实现两个分布式服务（订单服务、库存服务）共同完成一件事即订单支付成功自动减库存，这里的关键是如何保证两个分布式服务的事务的一致性。
        尝试解决上边的需求，在订单服务中远程调用减库存接口，伪代码如下：
        
        订单支付结果通知方法｛更新支付表中支付状态为“成功”。远程调用减库存接口减库存。｝
        
        上边的逻辑说明：
        
        更新支付表状态为本地数据库操作。
        远程调用减库存接口为网络远程调用请求。
        为保存事务上边两步操作由spring控制事务，当遇到Exception异常则回滚本地数据库操作。
        问题如下：
        如果更新支付表失败则抛出异常，不再执行远程调用，此设想没有问题。
        如果更新支付表成功，网络远程调用超时会拉长本地数据库事务时间，影响数据库性能。
        如果更新支付表成功，远程调用减库存成功（减库存数据库commit成功），最后更新支付表commit失败，此时出现操作不一致。
        上边的问题涉及到分布式事务控制。
        
        什么是分布式事务
        
        什么是分布式系统：
        
        部署在不同结点上的系统通过网络交互来完成协同工作的系统。
        
        比如：充值加积分的业务，用户在充值系统向自己的账户充钱，在积分系统中自己积分相应的增加。充值系统和积分系统是两个不同的系统，一次充值加积分的业务就需要这两个系统协同工作来完成。
        
        什么是事务：
        
        事务是指由一组操作组成的一个工作单元，这个工作单元具有原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。
        
        原子性：执行单元中的操作要么全部执行成功，要么全部失败。如果有一部分成功一部分失败那么成功的操作要全部回滚到执行前的状态。
        
        一致性：执行一次事务会使用数据从一个正确的状态转换到另一个正确的状态，执行前后数据都是完整的。
        
        隔离性：在该事务执行的过程中，任何数据的改变只存在于该事务之中，对外界没有影响，事务与事务之间是完全的隔离的。只有事务提交后其它事务才可以查询到最新的数据。
        
        持久性：事务完成后对数据的改变会永久性的存储起来，即使发生断电宕机数据依然在。
        
        什么是本地事务：
        
        本地事务就是用关系数据库来控制事务，关系数据库通常都具有ACID特性，传统的单体应用通常会将数据全部存储在一个数据库中，会借助关系数据库来完成事务控制。
        
        什么是分布式事务：
        
        在分布式系统中一次操作由多个系统协同完成，这种一次事务操作涉及多个系统通过网络协同完成的过程称为分布式事务。这里强调的是多个系统通过网络协同完成一个事务的过程，并不强调多个系统访问了不同的数据库，即使多个系统访问的是同一个数据库也是分布式事务，如下图：
        
        另外一种分布式事务的表现是，一个应用程序使用了多个数据源连接了不同的数据库，当一次事务需要操作多个数据源，此时也属于分布式事务，当系统作了数据库拆分后会出现此种情况。
        
        分布式事务有哪些应用场景：
        
        电商系统中的下单扣库存
        电商系统中，订单系统和库存系统是两个系统，一次下单的操作由两个系统协同完成
        金融系统中的银行卡充值
        在金融系统中通过银行卡向平台充值需要通过银行系统和金融系统协同完成。
        教育系统中下单选课业务
        在线教育系统中，用户购买课程，下单支付成功后学生选课成功，此事务由订单系统和选课系统协同完成。
        SNS系统的消息发送
        在社交系统中发送站内消息同时发送手机短信，一次消息发送由站内消息系统和手机通信系统协同完成。
        
        如何进行分布式事务控制
        
        CAP理论
        
        CAP理论是分布式事务处理的理论基础：分布式系统在设计时只能在一致性(Consistency)、可用性(Availability)、分区容忍性(PartitionTolerance)中满足两种，无法兼顾三种。
        
        一致性(Consistency)：服务A、B、C三个结点都存储了用户数据，三个结点的数据需要保持同一时刻数据一致性。
        可用性(Availability)：服务A、B、C三个结点，其中一个结点宕机不影响整个集群对外提供服务，如果只有服务A结点，当服务A宕机整个系统将无法提供服务，增加服务B、C是为了保证系统的可用性。
        分区容忍性(Partition Tolerance)：分区容忍性就是允许系统通过网络协同工作，分区容忍性要解决由于网络分区导致数据的不完整及无法访问等问题。
        
        分布式系统不可避免的出现了多个系统通过网络协同工作的场景，结点之间难免会出现网络中断、网延延迟等现象，这种现象一旦出现就导致数据被分散在不同的结点上，这就是网络分区。
        
        分布式系统如何兼顾CAP？
        
        在保证分区容忍性的前提下一致性和可用性无法兼顾，如果要提高系统的可用性就要增加多个结点，如果要保证数据的一致性就要实现每个结点的数据一致，结点越多可用性越好，但是数据一致性越差。所以，在进行分布式系统设计时，同时满足“一致性”、“可用性”和“分区容忍性”三者是几乎不可能的。
        
        CAP有哪些组合方式？
        
        CA：放弃分区容忍性，加强一致性和可用性，关系数据库按照CA进行设计。
        AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多NoSQL数据库按照AP进行设计。
        说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允许暂时的数据不一致，只要最终在用户接受的时间内数据一致即可。
        CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按CP进行设计，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。说明：由于网络问题的存在CP系统可能会出现待等待超时，如果没有处理超时问题则整理系统会出现阻塞。
        BASE 理论
        
        强一致性和最终一致性
        CAP 理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP 即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。
        
        Base 理论介绍
        BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent （最终一致性）三个短语的缩写。
        BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务”。
        
        基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。
        
        软状态：由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
        
        最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。
        
        小结
        
        在分布式系统设计中AP的应用较多，即保证分区容忍性和可用性，牺牲数据的强一致性（写操作后立刻读取到最新数据），保证数据最终一致性。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。
        
        分布式事务一致性解决方案
        
        两阶段提交协议(2PC)
        
        为解决分布式系统的数据一致性问题出现了两阶段提交协议（2 Phase Commitment Protocol），两阶段提交由协调者和参与者组成，共经过两个阶段和三个操作，部分关系数据库如Oracle、MySQL支持两阶段提交协议，本节讲解关系数据库两阶段提交协议。
        
        2PC协议流程图
        
        第一阶段：准备阶段（prepare）
        协调者通知参与者准备提交订单，参与者开始投票。
        参与者完成准备工作向协调者回应Yes|NO。
        
        第二阶段：提交(commit)/回滚(rollback)阶段
        协调者根据参与者的投票结果发起最终的提交指令。
        如果有参与者没有准备好则发起回滚指令。
        
        应用实例
        
        一个下单减库存的例子：
        
        应用程序连接两个数据源。
        应用程序通过事务协调器向两个库发起prepare，两个数据库收到消息分别执行本地事务（记录日志），但不提交，如果执行成功则回复yes，否则回复no。
        事务协调器收到回复，只要有一方回复no则分别向参与者发起回滚事务，参与者开始回滚事务。
        事务协调器收到回复，全部回复yes，此时向参与者发起提交事务。如果参与者有一方提交事务失败则由事务协调器发起回滚事务。
        
        2PC的优缺点
        
        2PC的优点：实现强一致性，部分关系数据库支持（Oracle、MySQL等）。
        
        缺点：整个事务的执行需要由协调者在多个节点之间去协调，增加了事务的执行时间，性能低下。
        
        解决方案有：springboot+Atomikos or Bitronix
        
        3PC主要是解决协调者与参与者通信阻塞问题而产生的，它比2PC传递的消息还要多，性能不高。
        
        XA 方案
        
        2PC的传统方案是在数据库层面实现的，如 Oracle、MySQL 都支持 2PC 协议，为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及接口标准，国际开放标准组织 Open Group 定义了分布式事务处理模型DTP（Distributed Transaction Processing Reference Model）。
        
        为了让大家更明确 XA 方案的内容，下面以新用户注册送积分为例来说明：
        
        执行流程如下：
        
        应用程序（AP）持有用户库和积分库两个数据源。
        应用程序（AP）通过 TM 通知用户库 RM 新增用户，同时通知积分库RM为该用户新增积分，RM 此时并未提交事务，此时用户和积分资源锁定。
        TM 收到执行回复，只要有一方失败则分别向其他 RM 发起回滚事务，回滚完毕，资源锁释放。
        TM 收到执行回复，全部成功，此时向所有 RM 发起提交事务，提交完毕，资源锁释放。
        
        DTP 模型定义如下角色：
        
        AP（Application Program）：即应用程序，可以理解为使用 DTP 分布式事务的程序。
        RM（Resource Manager）：即资源管理器，可以理解为事务的参与者，一般情况下是指一个数据库实例，通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。
        TM（Transaction Manager）：事务管理器，负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个 RM。全局事务是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。
        DTP 模型定义TM和RM之间通讯的接口规范叫 XA，简单理解为数据库提供的 2PC 接口协议，基于数据库的 XA 协议来实现 2PC 又称为 XA 方案
        以上三个角色之间的交互方式如下：
        
        TM 向 AP 提供应用程序编程接口，AP 通过 TM 提交及回滚事务。
        TM 交易中间件通过 XA 接口来通知 RM 数据库事务的开始、结束以及提交、回滚等。
        
        小结
        
        整个 2PC 的事务流程涉及到三个角色 AP、RM、TM。AP 指的是使用 2PC 分布式事务的应用程序；RM 指的是资源管理器，它控制着分支事务；TM 指的是事务管理器，它控制着整个全局事务。
        
        （1）在准备阶段 RM 执行实际的业务操作，但不提交事务，资源锁定
        
        （2）在提交阶段 TM 会接受 RM 在准备阶段的执行回复，只要有任一个RM执行失败，TM 会通知所有 RM 执行回滚操作，否则，TM 将会通知所有 RM 提交该事务。提交阶段结束资源锁释放。
        
        XA方案的问题
        
        需要本地数据库支持XA协议。
        资源锁需要等到两个阶段结束才释放，性能较差。
        
        事务补偿 TCC
        
        TCC事务补偿是基于2PC实现的业务层事务控制方案，它是Try、Confirm和Cancel三个单词的首字母，
        
        含义如下
        
        Try 检查及预留业务资源完成提交事务前的检查，并预留好资源。
        Confirm确定执行业务操作对try阶段预留的资源正式执行。
        Cancel取消执行业务操作对try阶段预留的资源释放。
        
        应用实例
        
        下边用一个下单减库存的业务为例来说明：
        
        1、Try
        
        下单业务由订单服务和库存服务协同完成，在try阶段订单服务和库存服务完成检查和预留资源。
        订单服务检查当前是否满足提交订单的条件（比如：当前存在未完成订单的不允许提交新订单）。
        库存服务检查当前是否有充足的库存，并锁定资源。
        2、Confirm
        
        订单服务和库存服务成功完成Try后开始正式执行资源操作。
        订单服务向订单写一条订单信息。
        库存服务减去库存。
        3、Cancel
        
        如果订单服务和库存服务有一方出现失败则全部取消操作。
        订单服务需要删除新增的订单信息。
        库存服务将减去的库存再还原。
        TCC优缺点
        
        优点：最终保证数据的一致性，在业务层实现事务控制，灵活性好。
        缺点：开发成本高，每个事务操作每个参与者都需要实现try/confirm/cancel三个接口。
        注意：TCC的try/confirm/cancel接口都要实现幂等性，在为在try、confirm、cancel失败后要不断重试。
        
        什么是幂等性？幂等性是指同一个操作无论请求多少次，其结果都相同。
        幂等操作实现方式有：
        1、操作之前在业务方法进行判断如果执行过了就不再执行。
        2、缓存所有请求和处理的结果，已经处理的请求则直接返回结果。
        3、在数据库表中加一个状态字段（未处理，已处理），数据操作时判断未处理时再处理。
        
        可靠消息队列实现最终一致性
        
        本方案是将分布式事务拆分成多个本地事务来完成，并且由消息队列异步协调完成，如下图：
        下边以下单减少库存为例来说明：
        
        可以把MQ去掉不使用MQ
        
        1、订单服务和库存服务完成检查和预留资源。
        2、订单服务在本地事务中完成添加订单表记录和添加“减少库存任务消息”。
        3、由定时任务根据消息表的记录发送给MQ通知库存服务执行减库存操作。
        4、库存服务执行减少库存，并且记录执行消息状态（为避免重复执行消息，在执行减库存之前查询是否执行过此消息）。
        5、库存服务向MQ发送完成减少库存的消息。
        6、订单服务接收到完成库存减少的消息后删除原来添加的“减少库存任务消息”。
        
        实现最终事务一致要求：预留资源成功理论上要求正式执行成功，如果执行失败会进行重试，要求业务执行方法实现幂等。
        
        优缺点
        
        优点：
        由MQ按异步的方式协调完成事务，性能较高。
        不用实现try/confirm/cancel接口，开发成本比TCC低。
        
        缺点：
        此方式基于关系数据库本地事务来实现，会出现频繁读写数据库记录，浪费数据库资源，另外对于高并发操作不是最佳方案。
        
        分布式事务解决方案之最大努力通知
        
        什么是最大努力通知
        
        最大努力通知也是一种解决分布式事务的方案，下边是一个是充值的例子：
        交互流程：
        
        账户系统调用充值系统接口
        充值系统完成支付处理向账户发起充值结果通知，若通知失败，则充值系统按策略进行重复通知
        账户系统接收到充值结果通知修改充值状态
        账户系统未接收到通知会主动调用充值系统的接口查询充值结果
        
        通过上边的例子我们总结最大努力通知方案的目标：发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
        
        具体包括：
        
        有一定的消息重复通知机制。因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知
        消息校对机制。如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息来满足需求。
        
        最大努力通知与可靠消息一致性有什么不同？
        
        解决方案思想不同
        
        可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
        
        两者的业务应用场景不同
        
        可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
        
        技术解决方向不同
        
        可靠消息一致性要解决消息从发出到接收的一致性，即消息发出并且被接收到。最大努力通知无法保证消息从发出到接收的一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）
        
        解决方案
        
        通过对最大努力通知的理解，采用 MQ 的 ack 机制就可以实现最大努力通知。
        
        方案1：
        本方案是利用 MQ 的 ack 机制由 MQ 向接收通知方发送通知，流程如下：
        
        发起通知方将通知发给 MQ。使用普通消息机制将通知发给MQ。
        注意：如果消息没有发出去可由接收通知方主动请求发起通知方查询业务执行结果。（后边会讲）
        
        接收通知方监听 MQ。
        
        接收通知方接收消息，业务处理完成回应 ack。
        
        接收通知方若没有回应 ack 则 MQ 会重复通知。
        MQ会按照间隔 1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔，直到达到通知要求的时间窗口上限。
        
        接收通知方可通过消息校对接口来校对消息的一致性。
        方案 2：
        交互流程如下：
        
        发起通知方将消息发给 MQ。
        使用可靠消息一致方案中的事务消息保证本地事务和消息的原子性，最终将通知先发给 MQ。
        
        通知程序监听 MQ，接收 MQ 的消息。
        方案 1 中接收通知方直接监听 MQ，方案 2 中由通知程序监听 MQ。
        
        通知程序若没有回应 ack 则 MQ 会重复通知。
        通知程序通过互联网接口协议（如 http、webservice）调用接收通知方案接口，完成通知。
        通知程序调用接收通知方案接口成功就表示通知成功，即消费 MQ 消息成功，MQ 将不再向通知程序投递通知消息。
        
        接收通知方可通过消息校对接口来校对消息的一致性。
        
        方案1和方案2的不同点：
        
        方案 1 中接收通知方与 MQ 接口，即接收通知方案监听 MQ，此方案主要应用与内部应用之间的通知。
        方案 2 中由通知程序与 MQ 接口，通知程序监听 MQ，收到 MQ 的消息后由通知程序通过互联网接口协议调用接收通知方。此方案主要应用于外部应用之间的通知，例如支付宝、微信的支付结果通知。
        小结
        
        最大努力通知方案是分布式事务中对一致性要求最低的一种，适用于一些最终一致性时间敏感度低的业务；最大努力通知方案需要实现如下功能：
        
        消息重复通知机制
        消息校对机制
        分布式事务对比分析
        
        2PC 最大的诟病是一个阻塞协议。RM 在执行分支事务后需要等待 TM 的决定，此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度高，因此，这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并发较高以及子事务生命周期较长（long-running transactions）的分布式服务中。
        
        如果拿TCC事务的处理流程与2PC两阶段提交做比较，2PC 通常都是在跨库的 DB 层面，而 TCC 则在应用层面的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的粒度，使得降低锁冲突、提高吞吐量成为可能。而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现 Try、Conﬁrm、Cancel 三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。典型的使用场景：满减，登录送优惠券等。
        
        可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。典型的使用场景：注册送积分，登录送优惠券等。
        
        最大努力通知是分布式事务中要求最低的一种,适用于一些最终一致性时间敏感度低的业务；允许发起通知方处理业务失败，在接收通知方收到通知后积极进行失败处理，无论发起通知方如何处理结果都会不影响到接收通知方的后续处理；发起通知方需提供查询执行情况接口，用于接收通知方校对结果。典型的使用场景：银行通知、支付结果通知等。
        
        2PC TCC 可靠消息最大努力通知
        一致性强一致性最终一致性最终一致性最终一致性
        吞吐量低中高高
        实现复杂度易难中易
        
        总结
        
        以上讲了什么是分布式事务以及它的应用场景、如何进行分布式控制最后讲了分布式事务一致性的四种种解决方案以及对比分析。
        
        在条件允许的情况下，我们尽可能选择本地事务单数据源，因为它减少了网络交互带来的性能损耗，且避免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务，应首先从整体设计角度观察服务的拆分是否合理，是否高内聚低耦合？是否粒度太小？分布式事务一直是业界难题，因为网络的不确定性，而且我们习惯于拿分布式事务与单机事务 ACID 做对比。
        
        无论是数据库层的 XA、还是应用层 TCC、可靠消息、最大努力通知等方案，都没有完美解决分布式事务问题，它们不过是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。
        
        分布式事务框架，在这些理论基础上，都进行了或多或少的修订，也有不少创新。比如LCN框架（lock，confirm，notify），就抽象出了控制方和发起方的概念，感兴趣的可以自行了解。
        
        在互联网公司中，由于高并发量的诉求，在实际应用中，相对于强事务，大家普遍选用软事务进行业务处理。使用最多的，就是TCC、SAGA、本地消息表等解决方案。SAGA应对长事务特别拿手，但隔离性稍差；TCC一直型好并发高，但需要较多编码；本地消息表应用场景有限，耦合业务不能复用。各种解决方案都有它的利弊，一定要结合使用场景进行选择。
        
        在框架方面，阿里的seata（早些年叫fescar），已经得到了广泛应用，XA、TCC、SAGA等模式都支持，如果你需要这方面的功能，可以集成尝试一下。可参考我写的文章：Spring Cloud Alibaba 实战 Seata
        
        建筑资源网站大全关键词排名优化网站建设一站式服务公司网站推广软件网页设计是什么九江网站设计