3. OpenTelemetry 核心概念：Signal、Context Propagation、Span、Attributes、Resource
OpenTelemetry（OTel）是可观测性领域的统一标准。要构建缓存一致性的闭环可观测方案，必须先掌握其五大核心概念：Signal（信号）、Context Propagation（上下文传播）、Span（跨度）、Attributes（属性）和 Resource（资源）。这些概念共同构成了数据采集、关联与分析的骨架。
3.1 Signal（信号）：可观测性的三大支柱
Signal 是 OTel 采集的数据类型，对应可观测性的三大支柱：Traces（链路）、Metrics（指标）和 Logs（日志）。在缓存一致性场景中，三者缺一不可。
| Signal 类型 | 核心作用 | 缓存一致性场景示例 |
|---|---|---|
| Traces | 记录请求端到端的执行路径，展示调用关系与耗时 | 一次缓存穿透请求：从网关 → 应用 → 缓存 → 数据库的完整链路 |
| Metrics | 聚合统计系统运行状态，如速率、延迟、错误率 | 缓存命中率、缓存更新延迟、缓存与数据库不一致次数 |
| Logs | 记录离散的、带时间戳的事件详情 | 缓存失效事件、双写冲突日志、一致性校验失败记录 |
最佳实践：在缓存一致性方案中，Traces 用于定位“哪一步出错了”，Metrics 用于监控“整体健康度”，Logs 用于排查“具体错误原因”。三者通过 Trace ID 关联，形成闭环。
3.2 Context Propagation（上下文传播）：关联数据的纽带
Context Propagation 是 OTel 的核心机制，它负责在分布式系统的服务之间、线程之间传递上下文信息（如 Trace ID、Span ID）。没有上下文传播，Trace 就无法跨服务串联。
传播方式分为两种：
- 进程内传播：通过线程局部变量（ThreadLocal）或协程上下文传递。
- 进程间传播：通过 HTTP 头（如
traceparent）、gRPC 元数据或消息队列属性传递。
缓存一致性关键点：当应用更新缓存后，通过消息队列异步通知其他服务失效缓存时，必须将 Trace Context 注入到消息中。这样，消费者处理缓存失效的 Span 才能与生产者更新缓存的 Span 关联到同一条 Trace 上，实现端到端追踪。
3.3 Span（跨度）：链路追踪的基本单元
Span 是 Trace 中的最小工作单元，代表一个具有开始时间和结束时间的操作。一个 Trace 由多个 Span 组成，形成树状结构。
Span 的关键属性：
- Span ID：全局唯一标识。
- Parent Span ID：父 Span 的 ID，用于构建父子关系。
- Trace ID：所属 Trace 的 ID。
- Span Kind：标识 Span 的角色（Client、Server、Internal、Producer、Consumer）。
- Start / End Timestamp：操作的起止时间。
- Status：操作结果（Unset、Ok、Error）。
缓存一致性陷阱：在异步缓存失效场景中，如果消费者 Span 的 Parent Span ID 没有正确设置为生产者 Span 的 ID，Trace 将被割裂。务必在消息中传递
traceparent，并在消费者端手动恢复 Context。
3.4 Attributes（属性）：Span 的元数据
Attributes 是键值对（Key-Value），用于为 Span、Metric 或 Log 附加描述性元数据。它们提供了丰富的上下文信息，便于后续的过滤、分组和分析。
缓存一致性场景中推荐的 Attributes：
| 属性键（Key） | 值类型 | 示例值 | 说明 |
|---|---|---|---|
cache.key |
string | user:123:profile |
被操作的缓存键 |
cache.type |
string | redis / memcached |
缓存中间件类型 |
cache.operation |
string | get / set / delete |
缓存操作类型 |
cache.hit |
boolean | true / false |
是否命中缓存 |
db.system |
string | mysql / postgresql |
数据库类型（缓存回源时） |
consistency.check.result |
string | consistent / inconsistent |
一致性校验结果 |
语义约定：OTel 定义了 Semantic Conventions（语义约定），推荐使用标准化的属性键名（如
db.system、messaging.system）。在缓存场景中，建议遵循 cache.* 命名空间，确保数据在不同工具间可互操作。
3.5 Resource（资源）：描述数据来源的实体
Resource 代表生成可观测性数据的实体，通常是一个服务实例、一个容器或一台主机。Resource 信息会附加到该实体产生的所有 Signal 上，用于标识数据来源。
常见的 Resource 属性：
service.name：服务名称（如user-service）。service.version：服务版本（如1.2.3）。host.name：主机名。deployment.environment：部署环境（如production、staging）。telemetry.sdk.language：SDK 语言（如java、python）。
3.6 核心概念在缓存一致性中的协作
在缓存一致性闭环可观测方案中，这五个概念协同工作：
- Resource 标识是哪个服务（如
order-service）发出的数据。 - Span 记录每次缓存操作（如
Redis SET、Cache Invalidation）的耗时和状态。 - Attributes 为 Span 补充缓存键、操作类型、命中结果等关键信息。
- Context Propagation 确保更新缓存和失效缓存的操作属于同一条 Trace。
- Signal（Trace / Metric / Log） 分别从链路、聚合、事件三个维度提供可观测性数据。