分布式事务

基础概念

什么是事务

一次大的活动，它由不同的小活动组成，这些活动要么全成功，要么全失败

本地事物

本地中，大多数是通过关系性数据库来控制事务，这种事利用数据库本身特性实现，因此叫数据库事务。

由于应用主要靠关系数据库来控制事务，而数据库通常和应用在同一个服务器，所以基于关系型数据库的事务又称为本地事物。

数据库四大事务特性（ACID）

  • 原子性：构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失败的情况。
  • 一致性：事务执行前后，数据库的一致性约束没有被破坏。
  • 隔离性：数据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰。一个事务不能看到其他事务运行过程的中间状态。通过配置事务隔离级别可以避脏读，重复读问题。
  • 持久性：事务完成之后，该事务对数据库的更改会被持久化到数据库，且不会被回滚。

数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚

分布式事务

分布式系统将一个系统拆分成可独立部署的多个服务，服务于服务之间需要远程协作才能完成事务操作。

这种分布式系统下的不同服务之间通过网络远程协作完成的事务称为分布式事务

会分布式事务产生的场景

  1. 典型场景就是微服务架构：跨JVM进程产生分布式事务
  2. 单体系统访问多个数据库：跨数据库实例产生分布式事务
  3. 多服务访问同一个数据库实例：跨JVM进程产生分布式事务

分布式事务基础理论

CAP理论

理解CAP

CAP表示：一致性、可用性、分区容忍性

  • 一致性（C）：写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新的状态

    • 如何实现一致性
      • 写入主数据库后将数据同步到从数据库
      • 写入主数据库后在向从数据库期间要将从数据库锁定，待同步完成后在释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据。
    • 分布式系统一致性的特点：
      • 由于存在数据同步的过程，写操作的响应会有一定的延迟。
      • 为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。
      • 如果请求数据同步失败的节点则会返回错误信息，一定不会返回旧信息。

  • 可用性（A）：事务操作都可以得到响应结果，且不会出现响应超时或响应错误

    • 如何实现：
      • 从数据库接收到数据查询到请求则立即能够响应数据查询结果
      • 从数据库不允许出现响应超时或响应错误
    • 如何实现可用性
      • 写入主数据库后要将数据同步到从数据库
      • 由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定
      • 即使数据还没有同步过来，从数据库也要返回查询的数据，哪怕上旧数据，如果连旧数据也没有则可用按照约定返回一个默认信息，但不能返回错误或响应超时。
    • 分布式系统可用性的特点：
      • 所有请求都有响应，且不会出现响应超时或响应错误

  • 分区容忍性（P）：网络分区不可避免网络问题导致通信失败，但此时任何对外提供服务，这叫分区容忍性。

    • 如何实现
      • 主数据库向从数据库同步数据失败不影响读写操作
      • 其一个节点挂掉不影响另一个节点对外提供服务
    • 如何实现分区容忍性
      • 尽量使用异步取代同步问题，例如使用异步方式将数据从主数据库同步到从数据库，这样节点之间能有效的实现松耦合。
      • 添加从数据库节点，其中一个从节点挂掉其他从节点提供服务
    • 分布式系统分区容忍性的特点：
      • 分区容忍性上分布式系统具备的基本功能

CAP组合方式

在所有分布式事务场景中不会同时具备CAP三个特性，因为在具备了P的前提下C和A上不能共存的。

分区容忍性的含义是：

  1. 主数据库通过网络向从数据库同步数据，可用认为主从数据库部署在不同分区，通过网络进行交互。
  2. 当主数据库和从数据库之间的网络出现问题，不影响主数据库和从数据库对外提供服务
  3. 其一一个节点挂掉不影响另一个节点对外提供服务。

如果要实现一致性，则为了保证数据的一致会上锁，如果同步失败要返回错误信息和超时信息

如果要实现可用性，则不管什么时候都可以查询到数据，而且不会响应超时信息或返回错误信息

通过分析发现在瞒住P的前提下C和A存在矛盾性

CAP的组合方式：

  1. AP

    放弃一致性，追求可用性和分区容忍性，这是分布式系统最常用的选择

  2. CP

    放弃可用性，追求一致性和分区容忍性，我们的zookeeper就是追求的强一致性。

  3. CA

    放弃分区容忍性，即不进行分区，不考虑由于网络不通或节点挂掉的问题，则可以实现一致性和可用性，那么这个系统不是一个标准的分布式系统，关系性数据库就可以满足CA

BASE理论

  1. 理解强一致性和最终一致性

    CAP中的一致性要求在任何时间查询每个节点数据都必须一致，它强调的是强一致性

    最终一致性是允许可以在一段时间内每个节点的数据不一致，但是经过一段时候后数据必须一致。

  2. BASE理论介绍

    Base是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。是对CAP中AP的一个扩展，通过系统强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称为“柔性事务”

    • 基本可用：系统故障时，允许损失部分可用功能，保证核心功能可用
    • 软状态：由于不要求强一致，所以允许系统中存在中间状态（也叫状态），这个状态不影响系统可用性
    • 最终一致：指经过一段时间，所有节点数据都将达成一致

分布式事务解决方案

业内最常见的方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。

分布式事务解决方案之2PC（两阶段提交）

什么是2PC

2PC即两阶段提交协议，是将整个事务流程分为两个阶段，分别是准备阶段（P Prepare phase)和提交阶段(C Commit phase)

整个事务过程由事务管理器和参与者组成，事务管理器决定整个分布式事务的提交和回滚，事务参与者负责自己本地事物的提交和回滚。

在关系性数据库Oracle和Mysql支持两阶段提交协议

  1. 准备阶段：事务管理器给每个参与者发送准备（Prepare）消息，每个数据库参与者在本地执行事务，并写入本地Undo/Redo日志，此时事务没有提交。

    (Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数据文件)

  • 提交阶段：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息，；参与者根据事务管理器的指令执行提交或回滚操作，并释放事务处理过程中使用的锁资源。注意：必须在最后阶段释放锁资源。

分布式事务解决方案之TCC

什么是TCC

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try，确认Confirm，撤销Cancel。

  • Try操作：做业务检查及资源预留
  • Confirm操作：做业务确认操作
  • Cancel操作：实现一个与Try相反的操作及回滚操作。

TM首先发起所有的分布式事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

TCC分为是哪个阶段：

  1. Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，他它和后续的Confirm一起才能真正构成一个完整的业务逻辑。

  2. Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需要引入重试机制或人工处理。

  3. Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真多出错了，，需要引入重试机制或人工处理。

  4. TM事务管理器

    TM事务管理器可用实现为独立的服务，也可以让全局事务发起方充当TM的角色，TM独立出来是为了成为公用组件，是为了考虑系统解结构和软件复用

    TM在发起全局事务时生成全局事务记录，全局事务ID贯穿整个分布式事务调用链条，用来记录事务上下文，追踪和记录状态，由于Confirm和Cancel失败需要进行重试，因此需要实现为幂等，幂等性是指同一个操作无论请求多少次，其结果都相同。

分布式事务解决方案之可靠消息最终一致性

什么是可靠消息最终一致性

可靠消息最终一致性方案是指当事务发起方执行完成本地事物后并发出一条消息，事务参与方（消息消费者）一定能够接收到消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致

事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题

因此可靠消息最终一致性方案要解决一下几个问题：

  1. 本地事物与消息发送的原子性问题

    本地事物与消息发送到原子性问题即：事务发起方在本地事物执行成功后消息必须发出去，否则就丢弃消息。即实现本地事物和消息发送到原子性，要么都成功，要么都失败。本地事物与消息发送到原子性问题是实现可靠消息最终一致性方案的关键问题

  2. 事务参与方接收消息的可靠性

    事务参与方必须能够从消息队列接收到消息，如果接收消息失败可以重复接收消息

  3. 消息重复消费的问题

    由于网络的存在，若某一个消费节点超时但是消费成功，此时消息中间件会重复投递此消息，就导致了消息的重复消费。

分布式事务解决方案之最大努力通知

什么是最大努力通知

  • 目标

    发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。

  • 具体包括

    1. 有一定的消息重复通知机制（通知异常的情况）

      因为接收到通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。

    2. 消息校对机制（查询接口，可以主动校验）

      如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息信息未来满足需求

  • 最大努力通知与可靠消息一致性有什么不同？

    • 解决方案思想不同
      • 可靠消息一致性：发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
      • 最大努力通知：发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的借口查询业务处理结果，通知的可靠性关键在接收通知方。
    • 两者的业务应用场景不同
      • 可靠消息一致性关注的是交易过程的事务一致，以异步的方式完成交易。
      • 最大努力通知关注的是交易后的通知事务，即将交易结果可靠的通知出去。
    • 技术解决方向不同
      • 可靠消息一致性要解决消息从发出到接收到一致性，即消息发出并且被接收到。
      • 最大努力通知无法保证消息从发出到接收到一致性，只提供消息接收的可靠性机制。可靠机制是，最大努力通知的将消息通知给接收方，当消息无法被接收方接收时，由接收方主动查询消息（业务处理结果）

Coming soon…

分享文章

快来参与讨论吧~