架构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进行补偿。
- 适用场景：
- **高吞吐量要求：**在业务逻辑允许的情况下，通过异步提交提高系统吞吐量。
- **最终一致性要求：**在可以接受一定程度的脏写和脏读的情况下，确保最终一致性。