分布式事务及其解决办法

为什么有分布式事务

任何一个大型的项目都不可能在一个服务器上运行，一般都采用分布式的办法，部署到很多机器上，会拆分成好多微服务。每个服务都是连接自己的数据库，操作自己的数据。所以一定会设计到分布式事务。
分布式系统会经常出现异常，原因多种多样：机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP、存储数据丢失…

分布式系统定理

CAP定理

• 一致性：在分布式系统中，所有数据备份，在同一时刻是否同样的值
• 可用性：在集群中一部分节点故障后，集群整体是否还能相应客户端的读写请求
• 分区容错性：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区。分区容器的意思是，区间通信可能失败。
  CAP原则是指：这三个要素最多只能同时实现两点，不可能三者兼顾。一致性和可用性只能二选一，在分布式系统中一定要满足分区容错性一般是CP或者AP，分布式系统下不可能存在CA系统
  

分布式系统实现一致性

raft算法

raft算法动画介绍

面临的问题

对于大多数大型互联网那应用场景，主机众多，部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到99.9999%，即保证P和A，舍弃C。

BASE理论

是对CAP的延伸，思想是即使无法做到强一致性（CAP的一致性就是强一致性），但可以采用适当的弱一致性，即最终一致性。

• 基本可用（Basically Available）
  • 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
  • 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
• 软状态（Soft State）
  • 什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。
  • 软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
• 最终一致性（Eventually Consistent）
  • 上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

分布式系统事务几种方案

2PC模式（刚性事务）

二阶提交协议

• 第一阶段：事务协调器要求每个涉及到事务的数据库预提交此操作，并反应是否可以提交
• 第二阶段：事务协调器要求每个数据库提交数据。其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息
  
• 缺点
  • 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。
    当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
  • 单点故障。由于协调者的重要性，一旦协调者发生故障。
    参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
  • 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。 而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
  • 性能不理想

柔性事务（TCC事务补偿方案）

刚性事务：遵循ACID原则，强一致性
柔性事务：遵循BASE理论，最终一致性

核心思想 是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。分为三个阶段：

• Try 阶段:主要是对业务系统做检测（一致性）及资源预留（准隔离性）
• Confirm 阶段:主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。(Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。)
• Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。(Cancel 操作满足幂等性)

柔性事务（最大努力通知方案）

最大努力通知方案主要也是借助MQ消息系统来进行事务控制，这一点与可靠消息最终一致方案一样。看来MQ中间件确实在一个分布式系统架构中，扮演者重要的角色。最大努力通知方案是比较简单的分布式事务方案，它本质上就是通过定期校对，实现数据一致性。

• 业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
• 主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知。
• 主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息。
• 业务活动的被动方如果正常接收了数据，就正常返回响应，并结束事务。
• 如果被动方没有正常接收，根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。

柔性事务（可靠消息+最终一致性方案（异步确保型））

业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会正真发送