分布式事物

Posted 2021-02-17 cxyyh

一、分布式事物产生的背景

在微服务环境下，因为会根据不同的业务会拆分成不同的服务，比如会员服务、订单服务、商品服务等，让专业的人做专业的事情，每个服务都有自己独立的数据库，并且是独立运行，互不影响。

服务与服务之间通讯采用RPC远程调用技术，但是每个服务中都有自己独立的数据源，即自己独立的本地事务。两个服务相互通讯的时候，两个本地事务互不影响，从而出现分布式事务产生的原因。

传统项目大部分情况下，不会产生分布式事务，但是在项目中如果采用多数据源方式。 分布式环境

分布式事务案例说明-下单扣库

 

二、分布式事物

        1、分布式系统    

              部署在不同结点上的系统通过网络交互来完成协同工作的系统。比如：充值加积分的业务，用户在充值系统向自己的账户充钱，在积分系统中自己积分相应的增加。

               充值系统和积分系统是两个不同的系统，一次充值加积分的业务就需 要这两个系统协同工作来完成。

　　     2、事物

                所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。（执行单个逻辑功能的一组指令或操作称为事务）

                         原子性（Atomicity）：执行单元中的操作要么全部执行成功，要么全部失败。如果有一部分成功一部分失败那么成功的操作要全部回滚到执行前的状态

                          一致性（Consistency）:执行一次事务会使用数据从一个正确的状态转换到另一个正确的状态，执行前后数据都是完整的。

                          隔离性（Isolation）:在该事务执行的过程中，任何数据的改变只存在于该事务之中，对外界没有影响，事务与事务之间是完全的隔离的。只有事务提交后其它事务才可以查询到最新的数据。

                           持久性（Durability）：事务完成后对数据的改变会永久性的存储起来，即使发生断电宕机数据依然在。

           3、本地事物

                本地事务就是用关系数据库来控制事务，关系数据库通常都具有ACID特性，传统的单体应用通常会将数据全部存储在一个数据库中，会借助关系数据库来完成事务控制。

            4、分布式事物                          

                               在分布式系统中一次操作由多个系统协同完成，这种一次事务操作涉及多个系统通过网络协同完成的过程称为分布式事务。

                               这里强调的是多个系统通过网络协同完成一个事务的过程，并不强调多个系统访问了不同的数据库，即使多个系统访问的是同一个数据库也是分布式事务，

                               如下图：

                      

                   另外一种分布式事务的表现是，一个应用程序使用了多个数据源连接了不同的数据库，当一次事务需要操作多个数据源，此时也属于分布式事务，当系统作了数据库拆分后会出现此种情况。

                

    三、解决分布式事务基本思路

    1、ACID酸碱平衡理论   

                     如何保证强一致性呢？关系型数据库天生就是解决具有复杂事务场景的问题，关系型数据库完全满足ACID的特性。

          数据库管理系统中事务(transaction)的四个特性（分析时根据首字母缩写依次解释）：

                          原子性（Atomicity）：执行单元中的操作要么全部执行成功，要么全部失败。如果有一部分成功一部分失败那么成功的操作要全部回滚到执行前的状态

                          一致性（Consistency）:执行一次事务会使用数据从一个正确的状态转换到另一个正确的状态，执行前后数据都是完整的。

                         隔离性（Isolation）:在该事务执行的过程中，任何数据的改变只存在于该事务之中，对外界没有影响，事务与事务之间是完全的隔离的。只有事务提交后其它事务才可以查询到最新的数据。

                          持久性（Durability）：事务完成后对数据的改变会永久性的存储起来，即使发生断电宕机数据依然在。

                          所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。（执行单个逻辑功能的一组指令或操作称为事务）

    2、CAP（帽子 原理）

     由于对系统或者数据进行了拆分，我们的系统不再是单机系统，而是分布式系统，图解CAP理论·

  

       一致性: (Consistency):服务A、B、C三个结点都存储了用户数据， 三个结点的数据需要保持同一时刻数据一致性。

        可用性:（Availability):服务A、B、C三个结点，其中一个结点宕机不影响整个集群对外提供服务，如果只有服务A结点，当服务A宕机整个系统将无法提供服务，增加服务B、C是为了保证系统的可用性。

        P: Partition tolerance,分区容忍性。尽管网络上有部分消息丢失，但系统仍然可继续工作。  

       CAP原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。由于关系型数据库是单节点无复制的，因此不具有分区容忍性，但是具有一致性和可用性，而分布式的服务化系统都需要满足分区容忍性，

      那么我们必须在一致性和可用性之间进行权衡。如果在网络上有消息丢失，也就是出现了网络分区，则复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可用性:而如果             使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。

 

CAP有哪些组合方式？

 

  　   1、CA：放弃分区容忍性，加强一致性和可用性，关系数据库按照CA进行设计。

 

 　　2、AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多NoSQL数据库按照AP进行设计。

 

 　　说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允许暂时的数据不一致，只要最终在用户接受的时间内数据 一致即可。

 

　　3、CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按CP进行设计，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

 

 　　说明：由于网络问题的存在CP系统可能会出现待等待超时，如果没有处理超时问题则整理系统会出现阻塞。

 

　　总结：  在分布式系统设计中AP的应用较多，即保证分区容忍性和可用性，牺牲数据的强一致性（写操作后立刻读取到最新数据），

　　保证数据最终一致性。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。

 

     3、Base（碱）

        BASE 是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，由 eBay 架构师 Dan Pritchett 于 2008 年在《BASE: An Acid Alternative》（论文地址点 这里）论文中首次提       出。BASE 思想与 ACID 原理截然不同，它满足 CAP 原理，通过牺牲强一致性获得可用性， 一般应用于服务化系统的应用层或者大数据处理系统中，通过达到最终一致性来尽量满足业务的绝大多数需求。
     BASE 模型包含如下三个元素：

• BA：（Basically Available ），基本可用。
• S：（ Soft State），软状态，状态可以在一段时间内不同步。
• E：（Eventually Consistent ），最终一致，在一定的时间窗口内， 最终数据达成一致即可。

   关于最终一致的几种变种参见上面，在实际系统实践中，可以将若干变种结合起来，来实现各种业务需求。

      4、柔性事务和刚性事务

      柔性事务满足BASE理论（基本可用，最终一致）

     刚性事务满足ACID理论

    柔性事务分为

    1. 两阶段型

    2. 补偿型

    3. 异步确保型

    4. 最大努力通知型几种。 由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的

分析案例图:

 四、分布式事务解决方案

1、传统模式Jta+Atomikos

 传统项目中，比如项目中使用到多数据源的时候大多数采用jta+Atomikos解决分布式事务问题，jta+Atomikos底层是基于XA协议的两阶段提交方案。

XA协议:XA 事务的基础是两阶段提交协议。需要有一个事务协调者来保证所有的事务参与者都完成了准备工作(第一阶段)。

如果协调者收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。mysql 在这个XA事务中扮演的是参与者的角色，而不是协调者(事务管理器)。

JTA:JTA（java Transaction API）是JavaEE 13 个开发规范之一。java 事务API，允许应用程序执行分布式事务处理——在两个或多个网络计算机资源上访问并且更新数据。

JDBC驱动程序的JTA支持极大地增强了数据访问能力。事务最简单最直接的目的就是保证数据的有效性，

数据的一致性 Atomikos:Atomikos TransactionsEssentials 是一个为Java平台提供增值服务的并且开源类事务管理器

2、两阶段提交协议(2PC)

      参考:https://en.wikipedia.org/wiki/Two-phase_commit_protocol

第一阶段： 准备阶段：协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指令可以完成，则会写redo或者undo日志，让后锁定资源，执行操作，但并不提交。

第二阶段:提交(commit)/回滚(rollback)阶段：如果每个参与者明确返回准备成功，则协调者向参与者发送提交指令，参与者释放锁定的资源，如何任何一个参与者明确返回准备失败，则协调者会发送回滚指令，

参与者取消已经变更的事务，释放锁定的资源。

两阶段提交方案应用非常广泛，几乎所有商业OLTP数据库都支持XA协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

缺点：如果协调者宕机，参与者没有协调者指挥，则会一直阻塞。整个事务的执行需要由协调者在多个节点之间去协调，增加了事务的执行时间，性能低下。

优点：实现强一致性，部分关系数据库支持（Oracle、MySQL等）。

 一个下单减库存的例子：

 

1、   应用程序连接两个数据源。

2、   应用程序通过事务协调器向两个库发起prepare，两个数据库收到消息分别执行本地事务（记录日志），但不提交，如果执行成功则回复yes，否则回复no。

3、   事务协调器收到回复，只要有一方回复no则分别向参与者发起回滚事务，参与者开始回滚事务。

4、   事务协调器收到回复，全部回复yes，此时向参与者发起提交事务。如果参与者有一方提交事务失败则由事务协调器发起回滚事务。

3、三阶段提交协议（3PC）

      参考: https://en.wikipedia.org/wiki/Three-phase_commit_protocol

 

三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段：

询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。

准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；

                   如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功

提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；

                   如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致

4、 2PC和3PC的区别

增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，

只会减少这种情况的发生在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，

这也是根据概率统计上超时后默认成功的正确性最大 三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，

系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。

 5、事务补偿（TCC）

TCC事务补偿是基于2PC实现的业务层事务控制方案，它是Try、Confirm和Cancel三个单词的首字母，含义如下：

1、 Try 检查及预留业务资源

 完成提交事务前的检查，并预留好资源。

2、Confirm 确定执行业务操作

 对try阶段预留的资源正式执行。

3、Cancel 取消执行业务操作  对try阶段预留的资源释放。

下边用一个下单减库存的业务为例来说明：

1、Try

下单业务由订单服务和库存服务协同完成，在try阶段订单服务和库存服务完成检查和预留资源。

订单服务检查当前是否满足提交订单的条件（比如：当前存在未完成订单的不允许提交新订单）。

库存服务检查当前是否有充足的库存，并锁定资源。

2、Confirm

订单服务和库存服务成功完成Try后开始正式执行资源操作。

订单服务向订单写一条订单信息。

库存服务减去库存。

3、Cancel

如果订单服务和库存服务有一方出现失败则全部取消操作。

订单服务需要删除新增的订单信息。

库存服务将减去的库存再还原。

优点：最终保证数据的一致性，在业务层实现事务控制，灵活性好。

缺点：开发成本高，每个事务操作每个参与者都需要实现try/confirm/cancel三个接口。

注意：TCC的try/confirm/cancel接口都要实现幂等性，在为在try、confirm、cancel失败后要不断重试。

什么是幂等性？

 幂等性是指同一个操作无论请求多少次，其结果都相同。

幂等操作实现方式有：

1、 操作之前在业务方法进行判断如果执行过了就不再执行。

2、 缓存所有请求和处理的结果，已经处理的请求则直接返回结果。

3、在数据库表中加一个状态字段（未处理，已处理），数据操作时判断未处理时再处理。

 6、消息队列实现最终一致

本方案是将分布式事务拆分成多个本地事务来完成，并且由消息队列异步协调完成，如下图：下边以下单减少库存为例来说明：

1、订单服务和库存服务完成检查和预留资源。

2、订单服务在本地事务中完成添加订单表记录和添加“减少库存任务消息”。

3、 由定时任务根据消息表的记录发送给MQ通知库存服务执行减库存操作。

4、库存服务执行减少库存，并且记录执行消息状态（为避免重复执行消息，在执行减库存之前查询是否执行过此消息）。

5、库存服务向MQ发送完成减少库存的消息。

6、订单服务接收到完成库存减少的消息后删除原来添加的“减少库存任务消息”。

实现最终事务一致要求：预留资源成功理论上要求正式执行成功，如果执行失败会进行重试，要求业务执行方法实现幂等。

优点 ：

 

由MQ按异步的方式协调完成事务，性能较高。

 

不用实现try/confirm/cancel接口，开发成本比TCC低。

 

缺点：

 

此方式基于关系数据库本地事务来实现，会出现频繁读写数据库记录，浪费数据库资源，另外对于高并发操作不是最佳方案。