分布式事务解决方案

分布式事务解决方案

• 一．什么是事务
  • 事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。
    事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所有操作。
• 二．事务的 ACID
  • 事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（Isolation）和持续性（ Durability）。这四个特性简称为 ACID 特性。
  • 1 、原子性
    • 事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做
  • 2 、一致性
    • 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
  • 3 、隔离性
    • 一个事务的执行不能被其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
  • 4 、持续性
    • 也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

• 三.MySQL中的事务处理过程

  • MySQL 本身不提供事务支持，而是开放了存储引擎接口，由具体的存储引擎来实现，具体来说支持 MySQL 事务的存储引擎就是 InnoDB。

  • 存储引擎实现事务的通用方式是基于 redo log 和 undo log。

  • 简单来说，redo log 记录事务修改后的数据, undo log 记录事务前的原始数据。

  • 所以当一个事务执行时实际发生过程简化描述如下：

    • 1、先记录 undo/redo log，确保日志刷到磁盘上持久存储。
    • 2、更新数据记录，缓存操作并异步刷盘。
    • 3、提交事务，在 redo log 中写入 commit 记录。
    • 4、在 MySQL 执行事务过程中如果因故障中断，可以通过 redo log 来重做事务或通过 undo log 来回滚，确保了数据的一致性。

这些都是由事务性存储引擎来完成的，但 binlog 不在事务存储引擎范围内，而是由 MySQL Server 来记录的。

那么就必须保证 binlog 数据和 redo log 之间的一致性，所以开启了 binlog 后实际的事务执行就多了一步，如下：

• 1、先记录 undo/redo log，确保日志刷到磁盘上持久存储。
• 2、更新数据记录，缓存操作并异步刷盘。
• 3、将事务日志持久化到 binlog。
• 4、提交事务，在 redo log 中写入commit记录。
  这样的话，只要 binlog 没写成功，整个事务是需要回滚的，而 binlog 写成功后即使 MySQL Crash 了都可以恢复事务并完成提交。

要做到这点，就需要把 binlog 和事务关联起来，而只有保证了 binlog 和事务数据的一致性，才能保证主从数据的一致性。

所以 binlog 的写入过程不得不嵌入到纯粹的事务存储引擎执行过程中，并以内部分布式事务（xa 事务）的方式完成两阶段提交。

• 四.分布式事务

  • 数据库的分库分表
    • 当我们的单个数据库的性能产生瓶颈的时候，我们可能会对数据库进行分区，这里所说的分区指的是物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID几乎是很难达到，或者即使能达到那么效率和性能会大幅下降，最为关键的是再很难扩展新的分区了，这个时候如果再追求集群的ACID会导致我们的系统变得很差，这时我们就需要引入一个新的理论原则来适应这种集群的情况，就是 CAP 原则或者叫CAP定理，那么CAP定理指的是什么呢？
  • SOA 服务化
    • 服务化将单机应用，拆分为多个服务，常见包括用户中心、库存中心、订单中心、商品中心。

• 五.DTP简介

  • X/Open DTP(X/Open Distributed Transaction Processing Reference Model)是X/Open 这个组织定义的一套分布式事务的标准，也就是了定义了规范和API接口，由厂商进行具体的实现

  • X/Open DTP 定义了三个组件： AP，TM，RM

    • AP(Application Program)：也就是应用程序，可以理解为使用DTP的程序
    • RM(Resource Manager)：资源管理器，这里可以理解为一个DBMS系统，或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制。资源必须实现XA定义的接口
    • TM(Transaction Manager)：事务管理器，负责协调和管理事务，提供给AP应用程序编程接口（TX协议）以及管理资源管理器
    • 其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之间可以通信，DTP模型里面定义了XA接口，TM 和 RM 通过XA接口进行双向通信，例如:TM通知RM提交事务或者回滚事务，RM把提交结果通知给TM。AP和RM之间则通过RM提供的Native API 进行资源控制，这个没有进行约API和规范，各个厂商自己实现自己的资源控制，比如Oracle自己的数据库驱动程序。

  其中在DTP定了以下几个概念：

  - 事务：一个事务是一个完整的工作单元，由多个独立的计算任务组成，这多个任务在逻辑上是原子的。
  
  - 全局事务：对于一次性操作多个资源管理器的事务，就是全局事务
  
  - 分支事务：在全局事务中，某一个资源管理器有自己独立的任务，这些任务的集合作为这个资源管理器的分支任务
  
  - 控制线程：用来表示一个工作线程，主要是关联AP,TM,RM三者的一个线程，也就是事务上下文环境。简单的说，就是需要标识一个全局事务以及分支事务的关系。
  
    ![image](https://img.haomeiwen.com/i325120/f049e242900b7676.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
  

• 六、2PC(两阶段提交协议) 保证分布式事务的完整性

  • 两阶段提交协议（Two-phase Commit，2PC）经常被用来实现分布式事务。一般分为协调器C和若干事务执行者Si两种角色，这里的事务执行者就是具体的数据库，协调器可以和事务执行器在一台机器上。
  image

  • 1、 我们的应用程序（client）发起一个开始请求到TC；

  • 2、 TC先将<prepare>消息写到本地日志，之后向所有的Si发起<prepare>消息。以支付宝转账到余额宝为例，TC给A的prepare消息是通知支付宝数据库相应账目扣款1万，TC给B的prepare消息是通知余额宝数据库相应账目增加1w。为什么在执行任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭证 的效果，如果没有本地日志（凭证），出问题容易死无对证；

  • 3、 Si收到<prepare>消息后，执行具体本机事务，但不会进行commit，如果成功返回<yes>，不成功返回<no>。同理，返回前都应把要返回的消息写到日志里，当作凭证。

  • 4、 TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后执行事务abort操作。

  • 注：TC或Si把发送或接收到的消息先写到日志里，主要是为了故障后恢复用。如某一Si从故障中恢复后，先检查本机的日志，如果已收到<commit >，则提交，如果<abort >则回滚。如果是<yes>，则再向TC询问一下，确定下一步。如果什么都没有，则很可能在<prepare>阶段Si就崩溃了，因此需要回滚。

  • 现如今实现基于两阶段提交的分布式事务也没那么困难了，如果使用Java，那么可以使用开源软件atomikos(http://www.atomikos.com/)来快速实现。

  • 不过但凡使用过的上述两阶段提交的同学都可以发现性能实在是太差，根本不适合高并发的系统。为什么？

    • 1、两阶段提交涉及多次节点间的网络通信，通信时间太长！
    • 2、事务时间相对于变长了，锁定的资源的时间也变长了，造成资源等待时间也增加好多！

  正是由于分布式事务存在很严重的性能问题，大部分高并发服务都在避免使用，往往通过其他途径来解决数据一致性问题。

  • 业务与消息解耦方式

    -  1、支付宝在扣款事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送，只有消息发送成功后才会提交事务；
    
    -  2、当支付宝扣款事务被提交成功后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送该消息；
    
    -  3、当支付宝扣款事务提交失败回滚后，向实时消息服务取消发送。在得到取消发送指令后，该消息将不会被发送；
    
    -  4、对于那些未确认的消息或者取消的消息，需要有一个消息状态确认系统定时去支付宝系统查询这个消息的状态并进行更新。为什么需要这一步骤，举个例子：假设在第2步支付宝扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确认发送”，从而导致消息不能被发送。
    
    -  优点：消息数据独立存储，降低业务系统与消息系统间的耦合；
    
    -  缺点：一次消息发送需要两次请求；业务处理服务需要实现消息状态回查接口。
    

• 七、2pc的数据一致性问题

  • a、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
  • b、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态
  • c、二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交
  • d、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去

• 八、3pc提交协议

  • 1、canCommit 询问
  • 2、preCommit 准备
  • 3、doCommit 实行
  image

• 九.分布式事务的实现

  • JOTM(java open transaction manager)
  • Atomikos
    • https://www.cnblogs.com/happyflyingpig/p/8003957.html

• 四. 可靠消息分布式事务流程图

可靠消息分布式事务流程图.png image