架构03-事务处理

零、文章目录

架构03-事务处理

1、本地事务实现原子性和持久性

（1）事务类型

**本地事务：**单个服务、单个数据源
**全局事务：**单个服务、多个数据源
**共享事务：**多个服务、单个数据源
**分布式事务：**多个服务、多个数据源

（2）事务意义

**一致性：**保证系统中的数据正确，不同数据间不会产生矛盾。
ACID特性：
- **原子性（Atomicity）：**多个对数据的修改要么同时成功，要么一起被撤销。
- **隔离性（Isolation）：**不同业务处理过程中的数据读写互相独立，不会彼此影响。
- **持久性（Durability）：**成功提交的数据修改能够正确地被持久化，不丢失数据。

（3）事务场景

**事务的概念：**最初源于数据库，但现代信息系统中，包括数据库、缓存、事务内存、消息、队列、对象文件存储等场景都可能涉及事务处理。
**复杂性：**单个服务使用单个数据源时较容易实现一致性，但涉及多个数据源或多个服务时变得困难。

（4）本地事务

**定义：**仅操作特定单一事务资源的事务，不需要全局事务管理器进行协调。
**适用场景：**单个服务使用单个数据源。
实现原理
- **原子性：**保证事务的多个操作要么都生效，要么都不生效。
- **持久性：**保证事务生效后，修改的内容不会因任何原因被撤销或丢失。

（5）实现方法

Commit Logging：
- **原理：**先将修改数据的操作记录到日志中，日志记录成功后，再对数据进行修改。
- **优点：**简单清晰，易于实现。
- **缺点：**性能较低，不允许在事务提交前写入变动数据。
Write-Ahead Logging：
- **原理：**允许在事务提交前写入变动数据，通过 Undo Log 和 Redo Log 来实现崩溃恢复。
- 步骤：
  - **分析阶段（Analysis）：**扫描日志，找出待恢复的事务集合。
  - **重做阶段（Redo）：**重演历史，将包含 Commit Record 的日志写入磁盘。
  - **回滚阶段（Undo）：**根据 Undo Log 回滚未提交的事务。
- **优点：**性能较高，允许提前写入数据。
- **缺点：**实现复杂，涉及多种日志类型和复杂的恢复机制。

（6）ARIES理论

**定义：**基于语义的恢复与隔离算法，现代主流关系型数据库在事务实现上深受其影响。
**核心思想：**通过 Write-Ahead Logging 实现高效且严谨的日志记录与故障恢复。
组合策略：
- **FORCE：**事务提交后，要求变动数据必须同时完成写入。
- **STEAL：**事务提交前，允许变动数据提前写入。
- **最佳组合：**NO-FORCE + STEAL，性能最高但实现复杂。

2、数据库事务隔离性实现原理

（1）隔离性与并发

**定义：**隔离性保证每个事务各自读、写的数据互相独立，不会彼此影响。
**并发关系：**如果没有并发，所有事务全都是串行的，不需要任何隔离。但在现实中，并发是不可避免的，因此需要通过加锁等方式实现串行的数据访问。

（2）数据库提供的三种锁

写锁（Write Lock / X-Lock）
- 只有持有写锁的事务才能对数据进行写入操作。
- 数据加持着写锁时，其他事务不能写入数据，也不能施加读锁。
读锁（Read Lock / S-Lock）
- 多个事务可以对同一个数据添加多个读锁。
- 数据被加上读锁后不能被加上写锁，其他事务不能对该数据进行写入，但仍然可以读取。
- 持有读锁的事务可以将读锁升级为写锁，然后写入数据。
范围锁（Range Lock）
- 对某个范围直接加排他锁，在这个范围内的数据不能被读取，也不能被写入。
- 范围锁不仅禁止修改已有数据，还禁止在该范围内新增或删除任何数据。

（3）本地事务的四种隔离级别

可串行化（Serializable）
- **隔离强度：**最高
- **实现方式：**对事务所有读、写的数据全都加上读锁、写锁和范围锁。
- **性能影响：**并发能力最低，吞吐量最低。
可重复读（Repeatable Read）
- **隔离强度：**次高
- **实现方式：**对事务所涉及的数据加读锁和写锁，持续到事务结束，但不加范围锁。
- **问题：**幻读问题（Phantom Reads），即在事务执行过程中，两个完全相同的范围查询得到了不同的结果集。
读已提交（Read Committed）
- **隔离强度：**中等
- **实现方式：**对事务涉及的数据加的写锁持续到事务结束，但读锁在查询操作完成后立即释放。
- **问题：**不可重复读问题（Non-Repeatable Reads），即在事务执行过程中，对同一行数据的两次查询得到了不同的结果。
读未提交（Read Uncommitted）
- **隔离强度：**最低
- **实现方式：**对事务涉及的数据只加写锁，持续到事务结束，完全不加读锁。
- **问题：**脏读问题（Dirty Reads），即在事务执行过程中，一个事务读取到了另一个事务未提交的数据。

（4）多版本并发控制（MVCC）

基础原理：
- **版本管理：**对数据库的任何修改都不会直接覆盖之前的数据，而是产生一个新版副本与老版本共存。
- **版本字段：**每一行记录都有两个看不见的字段：CREATE_VERSION 和 DELETE_VERSION，记录事务 ID。
- 读取策略：
  - 可重复读：总是读取 CREATE_VERSION 小于或等于当前事务 ID 的记录，取最新版本。
  - 读已提交：总是取最新的版本即可，即最近被 Commit 的那个版本的数据。
**适用场景：**主要针对"读 + 写"场景的优化，如果是"写 + 写"场景，仍需加锁。

（5）乐观加锁与悲观加锁

**悲观加锁：**认为事务之间数据存在竞争是普遍情况，因此一开始就加锁。
**乐观加锁：**认为事务之间数据存在竞争是偶然情况，因此不一开始就加锁，而是出现竞争时再采取补救措施。
**性能影响：**竞争剧烈时，乐观锁可能更慢。

3、全局事务和共享事务

（1）全局事务

**定义：**全局事务（Global Transactions）适用于单个服务使用多个数据源的场景，是一种在分布式环境中追求强一致性的事务处理方案。
实现方式：
- XA 协议：
  - **定义：**1991年X/Open组织提出的事务处理框架，定义了全局事务管理器（Transaction Manager）和局部资源管理器（Resource Manager）之间的通信接口。
  - 核心组件：
    - 事务管理器：协调全局事务。
    - 资源管理器：驱动本地事务。
- JTA（Java Transaction API）：
  - javax.transaction.TransactionManager：用于容器事务管理。
  - javax.transaction.UserTransaction：用于手动开启、提交和回滚事务。
  - javax.transaction.xa.XAResource：资源定义接口，实现该接口的资源支持JTA。
两段式提交（2PC）：
- 阶段：
  - **准备阶段：**协调者询问参与者是否准备好提交。
  - **提交阶段：**协调者根据参与者回复决定提交或回滚。
- **优点：**保证了事务的一致性。
- 缺点：
  - **单点问题：**协调者宕机会影响所有参与者。
  - **性能问题：**多次远程调用和数据持久化导致性能较差。
  - **一致性风险：**网络不稳定可能导致数据不一致。
三段式提交（3PC）：
- 阶段：
  - CanCommit：协调者询问参与者事务是否可以完成。
  - PreCommit：参与者准备提交。
  - DoCommit：协调者发送提交指令。
- **优点：**改善了单点问题和回滚时的性能问题。
- **缺点：**并未解决一致性风险问题，甚至可能增加一致性风险。

（2）共享事务

**定义：**共享事务（Share Transactions）是指多个服务共用同一个数据源。
实现方式：
- **数据源与数据库的区别：**数据源是提供数据的逻辑设备，不一定与物理设备一一对应。
- **场景：**多个微服务共用同一个数据库。
- 方案：
  - **共享数据库连接：**同一应用进程内的不同持久化工具共享数据库连接。
  - **交易服务器：**新增中间角色，各服务通过交易服务器与数据库交互。
  - **消息队列：**使用消息队列服务器代替交易服务器，通过消息驱动更新数据库。
局限性：
- **性能问题：**数据库是系统中的瓶颈，难以扩展。
- **伪需求：**实际应用中较少使用，更多是理论上的可行性。

4、分布式事务

（1）分布式事务的挑战

分布式事务的复杂性
- **DTP 模型：**分布式事务相对于数据源而言，不涉及服务
- **分布式服务环境下的事务处理机制：**涉及多个服务同时访问多个数据源
**事例场景：**Fenix's Bookstore
- **服务拓扑：**账号、商家、仓库服务集群
- CAP 问题：
  - **一致性问题：**数据未及时同步导致错误交易
  - **可用性问题：**数据同步过程中暂停服务
  - **分区容忍性问题：**网络分区导致服务不正确
CAP 取舍
- **CP 系统：**放弃可用性，保证一致性和分区容忍性
  - **RDBMS 集群：**通过共享磁盘避免网络分区
  - **HBase：**RegionServer 宕机导致数据离线
- **AP 系统：**放弃一致性，保证可用性和分区容忍性
  - **NoSQL 库：**节点独立提供服务，可能出现不一致数据
  - **Redis 集群：**节点独立提供服务，可能出现不同数据

（2）CAP 理论与 ACID 原则的矛盾

CAP 理论
- **一致性（C）：**所有节点数据一致
- **可用性（A）：**系统不间断提供服务
- **分区容忍性（P）：**部分节点失联时系统仍能正确提供服务
ACID 原则
- **原子性（A）：**事务中的所有操作要么全部成功，要么全部失败
- **一致性（C）：**事务执行前后，数据库保持一致状态
- **隔离性（I）：**并发事务互不干扰
- **持久性（D）：**事务一旦提交，结果永久保存
矛盾点
- **CAP 理论：**分布式系统中最多只能同时满足两个特性
- **ACID 原则：**要求事务具有强一致性

（3）可靠事件队列

弱一致性
- **定义：**牺牲一致性，追求可用性和分区容忍性
- **最终一致性：**数据在一段时间内未被修改，最终达到一致状态
实现方式：可靠事件队列
- **BASE 模型：**基本可用、软状态、最终一致性
- 操作时序：
  - 用户发送交易请求
  - 系统评估操作顺序
  - 账户服务扣款并写入消息表
  - 消息服务轮询消息表，发送消息
  - 服务节点处理消息并返回结果
  - 消息服务重试直至成功
- 关键点
  - **幂等性：**消息重复发送不会导致重复操作
  - **最大努力交付：**通过持续重试保证可靠性

（4）TCC (Try-Confirm-Cancel)

特点：
- **强隔离性：**通过Try阶段预留资源，确保事务的隔离性。
- **业务侵入性：**需要将业务逻辑拆分为Try、Confirm和Cancel三个阶段，对业务代码有较高侵入性。
- **高性能：**在业务执行时只操作预留资源，减少锁和资源争用，具有较高的性能潜力。
实现过程：

复制代码

- **Try阶段：**
    * 检查业务可行性。
    * 预留业务资源。
- **Confirm阶段：**
    * 使用Try阶段准备的资源完成业务处理。
    * 满足幂等性，可能重复执行。
- **Cancel阶段：**
    * 释放Try阶段预留的业务资源。
    * 满足幂等性，可能重复执行。

适用场景：
- **强隔离性要求：**如在线书店的库存管理，需要避免超售问题。
- **高性能要求：**在业务逻辑允许的情况下，可以通过TCC提高系统吞吐量。

（5）SAGA

特点：
- **灵活性：**将大事务拆分为多个小事务，每个小事务都有对应的补偿操作。
- **低业务侵入性：**不需要为资源设计冻结状态和撤销冻结的操作，补偿操作相对容易实现。
- **最终一致性：**通过正向恢复或反向恢复策略，确保最终一致性。
实现过程：
- 子事务拆分：
  - 将大事务T拆分为多个子事务T1, T2, ..., Tn。
- 补偿操作设计：
  - 为每个子事务Ti设计对应的补偿操作Ci。
  - 满足幂等性和交换律。
- 恢复策略：
  - **正向恢复：**如果Ti提交失败，重试直至成功。
  - **反向恢复：**如果Ti提交失败，执行Ci补偿操作直至成功。
适用场景：
- **灵活性要求高：**如银行转账场景，无法要求银行冻结款项。
- **最终一致性要求：**在业务逻辑允许的情况下，可以通过SAGA确保最终一致性。

（6）AT事务（异步提交模式）

特点：
- **异步提交：**每个数据源单独提交，立即释放锁和资源，提高系统吞吐量。
- **牺牲隔离性：**可能产生脏写和脏读，需要通过全局锁机制来避免。
- **自动补偿：**通过保存SQL快照，自动生成逆向SQL进行补偿。
实现过程：
- SQL拦截：
  - 自动拦截所有SQL，保存修改前后结果的快照，生成行锁。
- 本地事务提交：
  - 通过本地事务提交快照和行锁。
- 分布式事务提交/回滚：
  - 成功提交时，清理日志数据。
  - 需要回滚时，根据日志数据生成逆向SQL进行补偿。
适用场景：
- **高吞吐量要求：**在业务逻辑允许的情况下，通过异步提交提高系统吞吐量。
- **最终一致性要求：**在可以接受一定程度的脏写和脏读的情况下，确保最终一致性。