4. 常见堆积原因分析（上）：消费者处理能力不足、慢消费、GC停顿

消息堆积是 Kafka 生产环境中最高频的故障之一。从链路追踪视角看，堆积的本质是 生产速率 > 消费速率，且差距持续累积。本章聚焦消费者端最常见的三类根因：处理能力不足、慢消费 和 GC 停顿。通过 OpenTelemetry 的 Span 链路，我们可以精准定位每一跳的耗时瓶颈。

4.1 消费者处理能力不足

处理能力不足是最直观的堆积原因。当消费者实例的 CPU、内存或 I/O 资源达到瓶颈时，单条消息的处理时间会显著增加。通过 OpenTelemetry 的 process Span 可以量化这一指标。

4.2 慢消费：业务逻辑与外部依赖

慢消费通常不是资源问题，而是业务代码或下游依赖导致的单条消息处理延迟。常见场景包括：

• 数据库写入慢： 每条消息都触发 INSERT/UPDATE，数据库连接池满或锁等待。
• RPC 调用超时： 消费逻辑中调用了外部 HTTP/gRPC 接口，响应缓慢。
• 复杂计算： 消息反序列化后执行正则匹配、图像处理或规则引擎。
• 批量处理不当： max.poll.records 设置过大，单次 poll 返回数千条消息，处理时间线性增长。

OpenTelemetry 的 嵌套 Span 是诊断慢消费的利器。以下代码展示了如何在消费逻辑中创建子 Span：

// 使用 OpenTelemetry SDK 在消费逻辑中创建子 Span
Span processSpan = tracer.spanBuilder("process.message")
    .setParent(Context.current())
    .setAttribute("message.key", record.key())
    .startSpan();

try (Scope scope = processSpan.makeCurrent()) {
    // 业务处理：数据库写入
    Span dbSpan = tracer.spanBuilder("db.insert")
        .setAttribute("db.system", "mysql")
        .setAttribute("db.statement", "INSERT INTO orders ...")
        .startSpan();
    try {
        orderDao.insert(record.value());
    } finally {
        dbSpan.end();
    }

    // 业务处理：外部 RPC
    Span rpcSpan = tracer.spanBuilder("rpc.call")
        .setAttribute("rpc.service", "inventory-service")
        .setAttribute("rpc.method", "checkStock")
        .startSpan();
    try {
        inventoryClient.checkStock(record.value());
    } finally {
        rpcSpan.end();
    }
} finally {
    processSpan.end();
}

通过上述嵌套 Span，在链路追踪系统中可以清晰看到：process.message 总耗时 = db.insert 耗时 + rpc.call 耗时 + 其他开销。如果 rpc.call 占比超过 80%，则慢消费的根因就是外部 RPC 超时。

4.3 GC 停顿：隐藏的“暂停杀手”

GC 停顿是 Java 消费者特有的堆积诱因。当 JVM 触发 Full GC 或长时间的 Young GC（如 G1 的 Mixed GC）时，应用线程会全局暂停（Stop-The-World）。在这段时间内，消费者无法执行 poll() 和 commitSync()，位移无法推进，堆积瞬时飙升。

GC 停顿的典型特征：

• 堆积曲线呈 阶梯状 上升：正常消费一段时间后，突然出现一段平坦的“无消费”区间。
• 消费者 JVM 的 GC 指标（jvm.gc.pause）出现 > 1 秒的尖刺。
• OpenTelemetry 的 process Span 中出现大段空白，Span 之间间隔不连续。

下图展示了 GC 停顿如何打断消费链路：

4.4 三类原因的链路追踪特征对比

在实际诊断中，通过 OpenTelemetry 的 Span 属性和 JVM 指标可以快速区分三类原因：

4.5 快速定位的 OpenTelemetry 查询示例

以下是一个在 Jaeger 中查找慢消费链路的查询示例：

# 查询条件：消费者服务，process Span 耗时 > 500ms
service.name = "order-consumer"
span.name = "process.message"
duration > 500ms
limit = 20

# 返回结果中关注嵌套 Span 的耗时分布
# 如果 db.insert 耗时占比 > 70%，优化数据库
# 如果 rpc.call 耗时占比 > 70%，优化外部调用或增加超时重试