1. 课程导论：Saga事务模式简介、补偿事务的核心概念、慢查询与连接池水位对Saga超时的影响
1.1 Saga事务模式概述
在微服务架构与分布式系统中，传统ACID事务因跨服务、跨数据库的约束而难以实施。Saga是一种长活事务（Long-Living Transaction）模式，它将一个全局事务拆分为一系列本地事务（Local Transaction），每个本地事务对应一个服务调用，并在失败时通过补偿事务（Compensating Transaction）回滚已提交的变更。
Saga事务的两种编排方式：
| 编排方式 | 核心机制 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Choreography（ choreography） | 每个服务在本地事务完成后，通过事件驱动触发下一个服务 | 订单-库存-支付链路较短、服务数量少 | 去中心化，无单点故障 | 事件追踪困难，循环依赖风险 |
| Orchestration（编排） | 引入协调器（Orchestrator）集中管理Saga执行与补偿 | 复杂多步骤、需要严格补偿顺序 | 流程可视化，补偿逻辑可控 | 协调器成为瓶颈与单点 |
关键认知： Saga不提供隔离性（Isolation），需要通过补偿语义（Compensation Semantics）或幂等设计来应对并发与部分失败。补偿事务是Saga区别于普通重试机制的核心特征。
1.2 补偿事务的核心概念
补偿事务是Saga中用于撤销已提交本地事务影响的操作。它必须满足以下原则：
- 幂等性（Idempotency）： 补偿操作可重复执行，结果一致。
- 可交换性（Commutativity）： 补偿与正向事务的执行顺序不影响最终状态。
- 最终一致性（Eventual Consistency）： 补偿完成后，系统达到业务上的一致状态。
补偿事务的典型生命周期：
- 正向执行： 服务A提交本地事务（如扣减库存）。
- 失败触发： 服务B执行失败，协调器或事件触发补偿流程。
- 补偿执行： 服务A执行补偿事务（如回滚库存）。
- 完成确认： 补偿事务提交，Saga进入失败终态。
常见陷阱： 补偿事务本身也可能失败（如数据库连接超时、网络分区）。此时Saga需要重试补偿，若重试仍失败，则进入“人工介入”或“死信队列”状态。补偿超时是分布式系统中最棘手的故障之一。
1.3 慢查询与连接池水位对Saga超时的影响
在Saga事务执行过程中，每个本地事务都需要从数据库连接池获取连接。当出现慢查询（Slow Query）时，连接被长时间占用，导致连接池水位上升，进而引发连锁反应：
| 问题阶段 | 现象 | 对Saga的影响 |
|---|---|---|
| 慢查询发生 | SQL执行时间超过阈值（如>1s） | 连接被占用，无法及时释放 |
| 连接池水位上升 | 活跃连接数接近或达到最大连接数 | 后续请求等待连接，超时概率增加 |
| Saga正向事务超时 | 本地事务获取连接超时 | Saga触发补偿，但补偿也可能因连接池满而失败 |
| 补偿事务超时 | 补偿操作无法获取连接或执行缓慢 | Saga进入“悬挂”状态，数据不一致 |
下图展示了慢查询如何通过连接池水位影响Saga补偿事务的执行路径：
1.4 故障排查的核心视角
本课程将围绕以下三个维度展开故障排查：
- 慢查询诊断： 如何定位慢SQL、分析执行计划、优化索引与查询结构。
- 连接池水位监控： 连接池参数配置（最大连接数、超时时间、队列大小）与实时水位监控。
- Saga超时链路追踪： 从正向事务超时到补偿事务超时的全链路日志与指标关联分析。
课程目标： 学完本课程后，你将能够独立排查因数据库性能问题导致的Saga补偿事务超时故障，并给出可落地的优化方案。