1. 课程导论：缓存一致性问题的背景、OpenTelemetry 在可观测性中的角色、采样策略优化的必要性
1.1 缓存一致性问题：分布式系统的“幽灵”
在微服务与分布式缓存（如 Redis、Memcached）广泛应用的今天，缓存一致性已成为影响系统正确性与用户体验的核心挑战。当多个服务实例并发读写同一缓存键，或数据库与缓存之间存在更新延迟时，数据不一致现象便会发生。
典型场景： 电商库存扣减。用户 A 与用户 B 同时下单，服务 A 更新数据库库存为 0，但缓存尚未失效；服务 B 读取到旧库存 1，导致超卖。此类问题在分布式链路中极难复现与定位。
缓存一致性问题通常分为以下三类：
| 类型 | 描述 | 典型根因 |
|---|---|---|
| 脏读 | 读取到未提交或已过期的数据 | 缓存更新滞后于数据库事务提交 |
| 不可重复读 | 同一事务内两次读取结果不一致 | 缓存被中间过程淘汰或更新 |
| 幻读 | 缓存集合数据与数据库实际集合不匹配 | 缓存键粒度设计不当，批量操作未同步 |
传统监控手段（如单点日志、聚合指标）难以捕捉这些瞬态不一致，因为它们往往发生在毫秒级的时间窗口内，且依赖特定的并发时序。
1.2 OpenTelemetry 在可观测性中的角色
OpenTelemetry（OTel）作为 CNCF 的标准化可观测性框架，提供了统一的 Traces（链路）、Metrics（指标）、Logs（日志） 采集与导出能力。在缓存一致性测试链路中，OTel 扮演着以下关键角色：
- 端到端追踪： 通过 Trace 串联服务 A → 缓存 → 数据库的完整调用链，精确记录每个操作的时序与状态。
- 上下文传播： 利用 W3C TraceContext 协议，将 TraceId/SpanId 透传至缓存操作与数据库事务，实现跨进程关联。
- 属性标注： 在 Span 中注入缓存键、操作类型（GET/SET/DEL）、缓存命中/未命中、数据库行版本号等关键属性，便于事后分析。
实践要点： 在缓存中间件（如 Redis 客户端）中集成 OTel 插桩，自动生成缓存操作 Span，无需业务代码侵入。这是实现缓存一致性可观测性的最低成本路径。
1.3 采样策略优化的必要性
在缓存一致性测试链路中，全量采集所有 Trace 数据会带来巨大的存储与计算开销，尤其在高并发压测场景下，每秒可能产生数十万条 Span。不加筛选地全量采集，会导致以下问题：
- 存储爆炸： 分布式追踪后端（如 Jaeger、Tempo）的存储成本线性增长，远超预算。
- 信噪比失衡： 99% 的正常请求 Trace 淹没了那 1% 的缓存不一致异常 Trace，排查效率极低。
- 性能干扰： 高频率的 Span 导出会增加应用线程的上下文切换开销，影响压测结果的准确性。
因此，必须引入智能采样策略，在保证缓存一致性异常不漏报的前提下，大幅降低数据采集量。优化目标如下：
| 维度 | 全量采集 | 优化后采样 |
|---|---|---|
| 数据量 | 100% Trace | ≤ 5% Trace（正常请求） |
| 异常捕获率 | 100% | ≥ 99.9%（缓存不一致场景） |
| 存储成本 | 高 | 降低 90% 以上 |
| 排查效率 | 低（大量噪声） | 高（聚焦异常链路） |
关键挑战： 缓存不一致属于“稀有事件”，常规的固定比率采样（如 1%）极易漏采。必须设计基于缓存操作特征（如缓存键、操作类型、响应时间异常）的自适应采样规则，确保异常链路被优先保留。