Pulsar订阅消息积压异常：发送1亿条仅显示93337条

我们向已存在订阅sub1的主题persistent://public/default/standalone发送了1亿条消息，存储占用符合预期，但执行pulsar-admin topics stats后发现sub1的msgBacklog仅为93337条，以下是输出详情：

root@pulsar:/pulsar/bin# ./pulsar-admin topics stats persistent://public/default/standalone
{
  "msgRateIn" : 0.0,
  "msgThroughputIn" : 0.0,
  "msgRateOut" : 0.0,
  "msgThroughputOut" : 0.0,
  "bytesInCounter" : 2346125445,
  "msgInCounter" : 15542302,
  "bytesOutCounter" : 0,
  "msgOutCounter" : 0,
  "averageMsgSize" : 0.0,
  "msgChunkPublished" : false,
  "storageSize" : 2346125445,
  "backlogSize" : 1942675515,
  "publishers" : [ ],
  "subscriptions" : {
    "sub1" : {
      "msgRateOut" : 0.0,
      "msgThroughputOut" : 0.0,
      "bytesOutCounter" : 0,
      "msgOutCounter" : 0,
      "msgRateRedeliver" : 0.0,
      "chuckedMessageRate" : 0,
      "msgBacklog" : 93337,
      "msgBacklogNoDelayed" : 93337,
      "blockedSubscriptionOnUnackedMsgs" : false,
      "msgDelayed" : 0,
      "unackedMessages" : 0,
      "type" : "Exclusive",
      "msgRateExpired" : 0.0,
      "lastExpireTimestamp" : 0,
      "lastConsumedFlowTimestamp" : 1700123065831,
      "lastConsumedTimestamp" : 0,
      "lastAckedTimestamp" : 0,
      "consumers" : [ ],
      "isDurable" : true,
      "isReplicated" : false
    }
  },
  "replication" : { },
  "deduplicationStatus" : "Disabled"
}

核心概念区分 #

先明确几个容易混淆的指标定义，避免概念误解：

• msgInCounter：主题累计成功接收的消息总数，这里显示为15542302（约1554万条），和你说的1亿条发送量存在显著差异，这是核心矛盾点之一。
• msgBacklog：订阅层面的未确认消息数，即消费者还未发送ACK确认的消息数量，仅代表该订阅未处理的消息，不是主题存储的所有消息。
• storageSize：主题在集群中存储的总字节数，这个指标符合预期说明主题确实存储了对应体量的数据，但和订阅堆积数是完全不同的统计维度。
• backlogSize：订阅堆积消息的总字节数，这里的1942675515字节是sub1未确认消息的总大小，与storageSize的差值是已经被ACK但还未达到保留期限的消息。

问题排查方向 #

1. 消息发送有效性验证
   发送1亿条但msgInCounter仅1554万，说明大部分消息可能未成功写入主题：

   • 检查生产者端日志，是否存在大量发送失败、超时或Broker返回的错误；
   • 确认生产者是否使用同步发送模式，是否正确处理了发送结果（比如忽略了失败回调）；
   • 查看Pulsar Broker日志，是否有消息写入限流、存储异常等记录。

2. 订阅消费与ACK行为分析
   sub1的msgBacklog为93337，结合msgOutCounter为0、lastAckedTimestamp为0，有两种可能：

   • 消费者从未启动过，但消息未触发过期（lastExpireTimestamp为0），需检查主题是否配置了消息保留策略，是否有部分消息被清理；
   • 消费者曾经启动并ACK了大部分消息，之后消费中断，剩余93337条未处理（比如消费进程崩溃、重启后未续接消费）。

3. 消息保留与过期配置检查
   执行pulsar-admin topics get-retention persistent://public/default/standalone查看主题的保留时间/大小限制；同时检查是否配置了消息TTL，确认是否有大量消息因过期被自动删除，导致msgInCounter与发送数不符。

4. 去重机制验证
   虽然输出中deduplicationStatus为Disabled，但如果发送过程中Broker曾经开启过去重，或者生产者端实现了重复消息过滤，也可能导致实际写入主题的消息数远低于发送量。

内容的提问来源于stack exchange，提问作者Alex Tbk