1. 分布式事务基础：概念、理论与典型场景
1.1 分布式事务概念
分布式事务是指参与事务的多个节点分布在不同的网络进程或物理机器上，通过协调机制保证所有节点上的数据操作满足 ACID 特性（原子性、一致性、隔离性、持久性）。在单体架构中，事务由本地数据库的锁和日志机制完成；在分布式环境下，网络延迟、节点故障、时钟偏差等因素使得传统事务模型无法直接适用，必须引入额外的协调协议（如两阶段提交、TCC、Saga）来达成全局一致性。
核心认知：分布式事务的本质是“跨节点的状态同步”。无论采用哪种实现方案，最终目标都是让多个独立数据源在业务上表现为一个逻辑整体。
1.2 CAP 定理与 BASE 理论
1.2.1 CAP 定理
CAP 定理（Brewer 定理）指出，一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 | 典型场景 |
|---|---|---|---|
| C | 一致性（Consistency） | 所有节点在同一时刻看到相同的数据副本 | 银行转账、库存扣减 |
| A | 可用性（Availability） | 每个请求都能获得非错误的响应（不保证数据最新） | CDN 缓存、社交动态 |
| P | 分区容错性（Partition Tolerance） | 系统在网络分区时仍能继续运行 | 跨机房部署、微服务通信 |
由于网络分区在分布式系统中是必然发生的，因此实际设计时只能在 CP（放弃可用性）和 AP（放弃强一致性）之间做选择。例如：ZooKeeper 选择 CP，Eureka 选择 AP。
1.2.2 BASE 理论
BASE 是 CAP 中 AP 路线的实践总结，由 eBay 架构师 Dan Pritchett 提出，包含三个要素：
- BA（Basically Available）：基本可用，允许部分功能降级，但核心服务持续响应。
- S（Soft State）：软状态，允许数据副本存在中间状态（如“待支付”“同步中”）。
- E（Eventually Consistent）：最终一致性，经过一段时间的异步同步后，所有副本最终达到一致。
实践启示：BASE 理论并非放弃一致性，而是将一致性从“强实时”放宽为“最终收敛”。在连接池水位巡检场景中，监控指标允许秒级延迟，属于典型的 BASE 适用场景。
1.3 分布式事务的典型场景
以下四类场景在微服务与容器化部署中最为常见，也是连接池水位巡检需要重点关注的上下文：
| 场景 | 描述 | 事务方案 | 连接池影响 |
|---|---|---|---|
| 跨库转账 | 账户 A 扣款、账户 B 加款，分属不同数据库实例 | XA / 2PC | 长事务持有连接，水位上升快 |
| 订单与库存 | 下单扣库存、支付后发货，涉及订单库与库存库 | TCC / Saga | Try 阶段预留资源，Cancel 时释放连接 |
| 多服务写扩散 | 用户注册后同步创建积分、优惠券、消息通知 | 消息表 + 本地事务 | 异步补偿，连接短暂占用 |
| 分布式调度 | 定时任务跨节点执行，需保证幂等与不重复 | 乐观锁 + 重试 | 短连接频繁获取/释放 |
1.4 分布式事务与连接池水位的关联
在 Docker 容器化部署中，每个微服务实例的连接池大小通常受容器内存限制（如 -Xmx 和 max_connections）。分布式事务的以下特征会直接影响连接池水位：
- 事务持续时间：XA 事务在 prepare 阶段会锁定资源，连接在事务完成前无法归还池中，导致活跃连接数居高不下。
- 补偿操作：TCC 的 Cancel 或 Saga 的补偿子事务会额外占用连接，若补偿逻辑重试次数过多，可能触发连接池耗尽。
- 异步消息积压：基于消息表的最终一致性方案中，本地事务写入消息表后，消费端拉取消息时同样需要数据库连接，积压会导致连接竞争。
巡检预警：当连接池活跃连接数持续超过 80% 且伴随分布式事务超时日志时，应优先排查事务协调器（如 Seata、LCN）的全局锁等待和分支事务重试次数，而非盲目扩容连接池。