📚 课程目录第1章课程导论

Saga链路追踪在压测场景测试与案例实战中的故障定位实践 - 第1节

1.1 Saga模式与分布式事务的演进

单体架构下，数据库本地事务（ACID）通过锁和日志保证强一致性。当系统拆分为微服务后，一个业务操作往往跨越多个服务、多个数据库实例，传统本地事务无法跨服务协调，分布式事务应运而生。

关键认知：分布式事务的核心矛盾在于——可用性与一致性之间的权衡。2PC 提供强一致性但牺牲了可用性（协调者单点、同步阻塞）；Saga 模式则通过补偿机制换取高可用，但需要业务层处理最终一致性和中间状态。

Saga 模式最早由 Hector Garcia-Molina 在 1987 年提出，最初用于处理长事务（Long Lived Transaction, LLT）。其核心思想是将一个大事务拆分为多个本地事务（子事务），每个子事务都有对应的补偿操作（Compensating Action）。

随着微服务架构的普及，Saga 模式经历了三个主要演进阶段：

经典 Saga（1987-2010）： 基于数据库日志和本地事务，通过编排脚本串联子事务，补偿逻辑硬编码。
微服务 Saga（2010-2018）： 引入事件驱动和消息队列，通过编排（Choreography）或协调（Orchestration）两种方式管理 Saga 流程。
云原生 Saga（2018-至今）： 结合 Service Mesh、可观测性标准（OpenTelemetry）、状态机引擎，支持动态补偿、链路追踪和压测场景的自动化故障注入。

实践建议：在压测场景库中，推荐优先使用协调模式构建 Saga 事务。协调器天然成为链路追踪的锚点，可以统一采集每个子事务的开始时间、结束时间、状态和补偿触发条件，大幅降低故障定位时的数据关联成本。

传统压测关注吞吐量（TPS）、响应时间（RT）和错误率，但在分布式 Saga 事务场景下，这些宏观指标无法定位以下问题：

痛点一：事务悬挂（Hanging Transaction） —— 压测过程中，某个子事务执行成功但补偿未触发，导致数据不一致，宏观指标却显示正常。
痛点二：补偿风暴（Compensation Storm） —— 高并发下，大量 Saga 事务同时触发补偿，补偿操作本身成为新的性能瓶颈，但压测报告只显示“错误率上升”。
痛点三：中间状态不可见 —— Saga 事务在执行过程中存在“已提交但未补偿”的中间状态，压测工具无法感知，故障排查时只能逐服务翻日志。

价值维度	具体说明	压测场景示例
事务边界可视化	通过 TraceId 串联 Saga 全链路，明确每个子事务的起止时间和依赖关系	压测中某订单 Saga 在“扣库存”步骤耗时突增，链路图直接定位到数据库连接池争用
补偿行为可观测	补偿操作作为独立 Span 记录，包含触发原因、执行耗时、重试次数	压测发现补偿 Span 数量异常增多，定位到某下游服务超时阈值设置过小
故障根因快速定位	从压测错误率上升的宏观指标，下钻到具体 Saga 实例的故障节点	错误率从 1% 飙升到 15%，链路追踪显示 90% 的故障集中在“支付服务”的某个 Pod
压测场景库质量评估	基于历史链路数据，评估压测场景对 Saga 事务的覆盖度（正常流、补偿流、超时流）	发现压测场景库中“库存不足触发补偿”的链路覆盖率为 0%，补充场景后提前发现 Bug

常见误区：不要认为“压测只关注性能指标，故障定位是监控系统的事”。在 Saga 模式下，性能劣化往往由事务补偿、数据不一致等业务逻辑问题引发。没有链路追踪的压测，就像没有仪表盘的飞机——你知道自己在飞，但不知道飞向哪里、哪个零件在冒烟。

本课程旨在帮助学员建立从“压测执行”到“故障定位”的完整闭环能力，具体目标如下：

理解 Saga 事务的链路追踪模型 —— 掌握 OpenTelemetry 在 Saga 场景下的 Span 设计、Context 传播和 Tag 规范。
构建压测场景库的链路数据采集体系 —— 学会在压测工具（如 JMeter、Gatling、Locust）中注入链路追踪上下文，实现压测流量与生产链路同构。
掌握基于链路追踪的故障定位方法论 —— 从 Trace 拓扑、Span 耗时、事件日志三个维度快速定位 Saga 事务悬挂、补偿风暴、数据不一致等典型故障。
落地压测场景库的持续优化机制 —— 利用历史链路数据反哺场景库设计，提升压测覆盖度和故障发现率。

课程共 30 章，分为四个阶段，建议按顺序学习：

前置知识：

实验环境：