4. 事务概念与ACID：分布式事务的ACID特性、本地事务与全局事务的区别、gRPC中的事务挑战
4.1 事务与ACID核心概念
事务（Transaction）是数据库系统中一组不可分割的操作单元，要么全部成功提交，要么全部失败回滚。ACID是事务必须满足的四个基本特性，也是衡量事务可靠性的黄金标准。
| 特性 | 全称 | 含义 | 违反后果 |
|---|---|---|---|
| A | 原子性 (Atomicity) | 事务中的所有操作要么全部完成，要么全部不做 | 部分更新导致数据不一致 |
| C | 一致性 (Consistency) | 事务执行前后，数据库必须满足所有约束规则 | 违反外键、唯一性等约束 |
| I | 隔离性 (Isolation) | 并发执行的事务互不干扰，效果如同串行 | 脏读、不可重复读、幻读 |
| D | 持久性 (Durability) | 已提交的事务结果永久保存，不因故障丢失 | 系统崩溃后数据丢失 |
关键认知：ACID并非分布式系统独有，而是从单机数据库继承而来的事务契约。在分布式环境中，维持ACID的代价呈指数级上升，因此常需要权衡与妥协。
4.2 本地事务 vs 全局事务
理解本地事务与全局事务的区别，是掌握分布式事务挑战的前提。两者在范围、协调机制和故障模型上存在本质差异。
| 对比维度 | 本地事务 | 全局事务（分布式事务） |
|---|---|---|
| 作用范围 | 单个数据库实例 | 跨多个数据库、服务、消息队列 |
| 协调者 | 数据库自身（如MySQL InnoDB） | 外部协调器（如XA、TCC、Saga） |
| 原子性保证 | 本地redo/undo日志 | 两阶段提交（2PC）或补偿机制 |
| 隔离性级别 | 可串行化、可重复读等 | 通常降级为读已提交或最终一致性 |
| 故障模型 | 单点故障，恢复简单 | 网络分区、节点宕机、超时等复杂故障 |
| 性能开销 | 低（毫秒级） | 高（秒级，锁持有时间长） |
工程启示：在gRPC微服务架构中，每个服务通常拥有自己的数据库实例，这意味着一次跨服务的业务操作天然就是全局事务。不能再用本地事务的思维去处理跨服务的数据一致性。
4.3 分布式事务的ACID挑战
当ACID从单机迁移到分布式环境时，每个特性都面临严峻挑战：
- 原子性挑战：多个服务各自执行本地事务，如何保证“全有或全无”？网络中断导致部分服务提交、部分回滚时，缺乏统一的原子性保障。
- 一致性挑战：全局约束（如账户余额非负）需要跨服务验证，但服务间数据同步存在延迟，中间状态可能违反业务规则。
- 隔离性挑战：分布式锁代价高昂，通常放弃严格隔离性，采用“最终一致性”或“读已提交”，导致脏读风险。
- 持久性挑战：单个服务持久化成功不代表全局持久化成功，协调者崩溃可能导致事务状态丢失。
常见误区：不要试图在gRPC调用中实现“完美ACID”。分布式系统理论（CAP、FLP）证明，在异步网络下严格ACID是不可能的。工程上应接受“最终一致性”并设计补偿机制。
4.4 gRPC中的事务挑战
gRPC作为微服务间通信的核心框架，其自身特性给事务实现带来了额外挑战：
- 无状态通信模型：gRPC默认不维护跨请求的会话状态，事务上下文（如事务ID、隔离级别）需要手动传播。
- 超时与重试：gRPC客户端超时后自动重试，可能导致同一操作被执行多次（幂等性问题），破坏原子性。
- 流式调用：服务端流、双向流场景下，事务边界难以界定——流中的每条消息是否属于同一事务？
- 拦截器局限：gRPC拦截器可以注入元数据，但无法感知业务逻辑中的事务边界，容易遗漏或重复提交。
- 网络不确定性：gRPC基于HTTP/2，网络分区、连接重置、消息乱序等故障模式增加了事务协调的复杂度。
实践建议：在gRPC服务中，推荐使用“显式事务传播”模式——在请求元数据中携带全局事务ID，并在服务端拦截器中统一管理事务生命周期。避免依赖隐式上下文传递。
4.5 事务边界与gRPC调用关系图
下图展示了典型gRPC微服务调用中，事务边界如何跨越多个服务，以及ACID特性在分布式环境下的退化情况：
4.6 事务隔离级别与gRPC实践对照
在gRPC分布式事务中，隔离级别的选择直接影响系统性能和一致性保证。下表对比了标准隔离级别与gRPC场景下的实践策略：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 | gRPC实践代价 | 推荐场景 |
|---|---|---|---|---|---|
| 读未提交 | 可能 | 可能 | 可能 | 极低，无锁 | 日志、监控等非关键数据 |
| 读已提交 | 避免 | 可能 | 可能 | 低，行级锁 | 大多数业务场景（默认选择） |
| 可重复读 | 避免 | 避免 | 可能 | 中，间隙锁 | 金融对账、库存扣减 |
| 可串行化 | 避免 | 避免 | 避免 | 极高，全表锁或谓词锁 | 极少使用，仅用于强一致性审计 |
gRPC隔离性策略：在跨服务调用中，建议每个服务内部使用“读已提交”级别，并通过业务层乐观锁（版本号）或分布式锁（如etcd）来避免并发冲突。不要依赖数据库的全局隔离性。
4.7 事务传播机制与gRPC元数据
在gRPC中实现事务传播，需要将事务上下文通过元数据（Metadata）在服务间传递。以下是常见的事务传播行为及其在gRPC中的映射：
| 传播行为 | 语义 | gRPC实现方式 | 典型场景 |
|---|---|---|---|
| REQUIRED | 加入已有事务，没有则新建 | 检查元数据中是否有事务ID，有则加入，无则创建新事务 | 订单创建流程 |
| REQUIRES_NEW | 挂起当前事务，新建独立事务 | 生成新事务ID，覆盖元数据中的旧ID | 日志记录、审计 |
| SUPPORTS | 有事务则加入，没有则以非事务方式执行 | 透传事务ID，但不强制要求 | 查询服务 |
| NOT_SUPPORTED | 以非事务方式执行，挂起当前事务 | 忽略传入的事务ID，不参与全局事务 | 缓存更新、异步通知 |
| NEVER | 必须以非事务方式执行，否则抛异常 | 检测到事务ID则拒绝请求 | 静态数据读取 |
注意：gRPC本身不提供事务传播机制，上述行为需要开发者通过拦截器（Interceptor）和元数据手动实现。建议在项目初期就定义统一的事务传播协议，避免后期混乱。
4.8 本章小结
- ACID是事务的黄金标准，但在分布式环境中每个特性都面临严峻挑战。
- 本地事务与全局事务在范围、协调、故障模型上存在本质差异，不能混用。
- gRPC的无状态模型、超时重试、流式调用等特性给事务实现带来额外复杂度。
- 工程实践中应接受“最终一致性”，通过补偿机制和幂等设计来应对分布式事务的局限性。
- 事务传播机制需要借助gRPC元数据和拦截器手动实现，建议统一协议并文档化。