跳转到内容
Max / Knowledge

分析、聚合与存储

Difficulty
Advanced
Status
Stable
Last reviewed
2026年8月

先给答案：主要失效边界集中在“高基数标签、重复上报、analyzer 堵塞”这些场景

Section titled “先给答案：主要失效边界集中在“高基数标签、重复上报、analyzer 堵塞”这些场景”

主要失效边界集中在“高基数标签、重复上报、analyzer 堵塞”这些场景。它们破坏的是容量、顺序、并发或生命周期前提；排查时应先确认状态是否仍由正确对象持有，再核对推进条件和清理路径。 理解分析、聚合与存储时，要先确认入口与状态归属，再跟踪控制流或数据流的推进顺序，最后落到对外可观察的结果。

主要失效边界集中在“高基数标签、重复上报、analyzer 堵塞”这些场景。它们破坏的是容量、顺序、并发或生命周期前提；排查时应先确认状态是否仍由正确对象持有，再核对推进条件和清理路径。

主要失效边界集中在“高基数标签、重复上报、analyzer 堵塞”这些场景。它们破坏的是容量、顺序、并发或生命周期前提；排查时应先确认状态是否仍由正确对象持有，再核对推进条件和清理路径。

OAP 接收一份 TraceSegment 后，不是只落一张 trace 表，而是通过 dispatcher 把它拆成服务、实例、端点、关系和指标等多种读模型。

Segment -> TraceAnalyzer -> DispatcherManager
        -> service/instance/endpoint/relation dispatchers
        -> DAO -> storage implementation

关键坐标：

  • TraceAnalyzer#analyze — oap-server/analyzer/agent-analyzer/src/main/java/org/apache/skywalking/oap/server/analyzer/provider/trace/parser/TraceAnalyzer.java:64
  • TraceAnalyzer#parse — oap-server/analyzer/agent-analyzer/src/main/java/org/apache/skywalking/oap/server/analyzer/provider/trace/parser/TraceAnalyzer.java:91
  • DispatcherManager#dispatch — oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/DispatcherManager.java:77
  • DispatcherManager#init — oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/DispatcherManager.java:51
  • SegmentDispatcher#dispatch — oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/manual/segment/SegmentDispatcher.java:35
  • ServiceTrafficDispatcher#dispatch — oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/manual/service/ServiceTrafficDispatcher.java:34
  • ServiceCallRelationDispatcher#dispatch — oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/manual/relation/service/ServiceCallRelationDispatcher.java:38
  • SourceReceiverImpl#receive — oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/source/SourceReceiverImpl.java:42
  • ModuleManager#start — oap-server/server-library/library-module/src/main/java/org/apache/skywalking/oap/server/library/module/ModuleManager.java:78

为什么拆成多个读模型

Section titled “为什么拆成多个读模型”

替代方案：只存原始 segment，查询时实时计算拓扑和指标。为什么不行：查询成本不可控，历史聚合会反复消耗 CPU。选择：写入时通过 dispatcher 生成面向查询的模型，以空间换查询延迟。

边界与踩坑

Section titled “边界与踩坑”
场景 现象 原因 规避
高基数标签 存储膨胀 service/endpoint 维度过细 控制标签和采样
重复上报 指标偏大 重试没有幂等边界 使用 segment id/时间窗口去重
analyzer 堵塞 数据延迟 聚合计算超出消费能力 批处理、分片和背压

可迁移知识

Section titled “可迁移知识”

观测平台通常采用写时展开：一次原始事件生成多个查询投影；投影之间通过稳定 ID 和时间窗口保持可追踪性。

面试锚点

  • 为什么一个 segment 要被分发成多个模型？
  • Dispatcher 和 Analyzer 的职责如何区分？
  • 高基数指标如何控制成本？
Section titled “Related”