分布式事务

一、什么是分布式事务？

1.它的由来

随着互联化的蔓延，各种项目都逐渐向分布式服务做转换。如今微服务已经普遍存在，本地事务已经无法满足分布式的要求，由此分布式事务问题诞生。 分布式事务被称为世界性的难题，目前分布式事务存在两大理论依据：CAP定律 BASE理论。

举例：

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

2.概述

• 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

• 数据库事务ACID特性：

  • 原子性
    所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。
  • 隔离性
    所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
  • 一致性
    事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。
  • 持久性
    所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

• 数据库事务的四种隔离级别：

  

二、相关理论

1.什么是CAP理论？

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

• 一致性

  在分布式系统中的所有数据备份，在同一时刻是否同样的值（可分为弱一致性、强一致性和最终一致性 ）。

• 可用性

  在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。意思是只要收到用户的请求，服务器就必须给出回应。

• 容错性

  以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

  

  上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。一般来说，只要是分布式系统，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。

• 结论

  一致性和可用性，为什么不可能同时成立？答案很简单，因为可能导致通信失败。

  • 如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，所以可用性不成立。
  • 如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。

2.什么是BASE理论？

• BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。

• BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

• Basically Available（基本可用）

  基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

  • 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
  • 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

• Soft state（软状态）

  软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

• Eventually consistent（最终一致性）

  最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

三、常见的分布式事务解决方案

1.基于XA协议的两阶段提交

• 什么是XA协议？

  • XA 协议由 OracleTuxedo 首先提出的，并交给 X/Open 组织，作为资源管理器与事务管理器的接口标准。
  • XA 协议采用两阶段提交方式来管理分布式事务。
  • 目前Oracle、Informix、DB2 和 Sybase 等各大数据库厂家都提供对 XA 的支持。
  • XA 就是 X/OpenDTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等，XA 接口函数由数据库厂 商提供。
  • X/Open 组织（即现在的 OpenGroup）定义了分布式事务处理模型。X/Open DTP 模型包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理 器（CRM）四部分。
  • 一般常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM） 是数据库，常见的通信资源管理器（CRM）是消息中间件。

• 一阶段提交

  

  如果在程序中开启了事务，那么在应用程序发出提交/回滚请求后，数据库执行操作， 而后将成功/失败返回给应用程序，程序继续执行。

  • 优点：一阶段提交协议相对简单，也很直观，它不用再与其他的对象交互，节省了判断步骤和时间，所以在性能上是在阶段提交协议中最好的。
  • 缺点：数据库确认执行 事务的时间较长，出问题的可能性就随之增大。如果有多个数据源，一阶段提交协议无法协调他们之间的关系。

• 二阶段提交

  

  二阶段协议通过将两层变为三层，增加了中间的管理者角色，从而协调多个数 据源之间的关系，二阶段提交协议分为两个阶段。

  • 第一阶段

    

    事务管理器通知参与该事务的各个资源管理器，通知他们开始准备事务。资源管理器接收到消息后开始准备阶段，写好事务日志并执行事务，但不提交，然后将是否就绪的消息返回给事务管理器。

  • 第二阶段`

  

  事务管理器在接受各个消息后，开始分析，如果有任意其一失败，则发送回滚命令，否则发送提交命令。各个资源管理器接收到命令后，执行并将提交消息返回给事务管理器。 事务管理器接受消息后，事务结束，应用程序继续执行。

  • 优点： 二阶段提交协议为了保证事务的一致性，不管是事务管理器还是各个资源管理器，每执行一步操作，都会记录日志，为出现故障后的恢复准备依据。

  • 缺点： 二阶段提交协议的存在的弊端是阻塞；在互联网海量流量的应用场景 中，吞吐量这个瓶颈也变得十分致命。

2.TCC解决方案

• 什么是TCC？

  TCC 是由支付宝架构师提供的一种柔性解决分布式事务解决方案，主要包括三个步骤。

  

• 执行原理

  • TCC 中事务的管理者是以一个独立的服务出现，而不是中间件。

  • TCC 方案在电商、金融领域落地较多，TCC 方案其实是XA协议两阶段提交的一种改进。

  • TCC 将整个业务逻辑的每个分支显式的分成了 Try、Confirm、Cancel 三个操作。Try 部分完成业务的准备工作，confirm 部分完成业务的提交，cancel 部分完成事务的回滚。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cv8Wq9z8-1615462843130)(LCN.assets/202003071550031.png)]

• 执行流程

  

• 优点

  • 让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

• 缺点

  • 业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作，应用侵入性较强，改造成本高。
  • 实现难度较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。
  • 为了满足一致性的要求，confirm 和 cancel 接口必须实现幂。

3.利用分布式事务中间件

分布式事务中间件其本身并不创建事务，而是基于对本地事务的协调从而达到事务一致性的效果。

• 比如阿里的GTS（https://www.aliyun.com/aliware/txc）

  

• 比如开源框架TX-LCN （https://github.com/codingapi/tx-lcn/wiki）