Pulsar消息积压与丢失：深度排查与故障定位指南

在Pulsar集群中，消息积压（Message Backlog）和消息丢失（Message Loss）是生产环境中极其严重的问题，它们直接影响业务的实时性和数据完整性。当常规的监控告警响起时，这仅仅是排查的开始。我们需要一套系统的、深入的排查方法，快速定位并解决问题。

一、排查总览：从宏观到微观

处理Pulsar消息积压或丢失，首先要避免盲目猜测。一个有效的排查流程应该遵循“宏观观测 -> 链路分析 -> 组件细查 -> 客户端验证”的思路。

1. 宏观健康度检查： 观察整个集群的CPU、内存、磁盘I/O、网络带宽使用率，初步判断是否存在资源瓶颈。
2. 消息流向链路分析： 确认是生产端（Producer）发送问题、Broker接收存储问题、BookKeeper持久化问题，还是消费端（Consumer）消费问题。
3. 核心组件深入诊断： 针对Broker、BookKeeper、ZooKeeper这三大核心组件，结合其日志、指标和内部状态进行精细化分析。
4. 客户端行为验证： 验证Producer和Consumer的配置与代码逻辑是否符合预期，是否存在误用。

二、深入排查维度与关键线索

1. Broker 节点排查

Broker负责消息的路由、负载均衡、代理以及与BookKeeper的交互。消息积压或丢失，Broker往往是第一道防线。

• 指标监控：
  • pulsar_broker_messages_in_total / pulsar_broker_messages_out_total：确认消息生产和消费速率是否异常。
  • pulsar_broker_subscriptions_backlog_size：直接反映主题订阅的积压情况。
  • pulsar_broker_connections：连接数是否过高，导致新建连接困难或现有连接不稳定。
  • pulsar_broker_jvm_memory_used_bytes / pulsar_broker_jvm_gc_time_seconds_total：JVM内存使用率和GC时间，高GC可能导致处理延迟。
  • pulsar_broker_topic_load_balancer_transfer_count：负载均衡器是否频繁转移Topic，可能暗示某些Broker过载或不稳定。
• 日志分析 (定位关键词)：
  • BrokerService.java / Topic.java 相关日志：查找 message backlog, GC overhead limit exceeded, memory pressure, connection reset by peer, failed to write entry to bookkeeper 等关键字。
  • "High GC activity": Broker进程长时间Full GC，会导致消息处理停滞。
  • "BookKeeperClient: Error writing entry": Broker无法将消息写入BookKeeper，通常指向BookKeeper问题。
  • "Client connection closed": 可能是客户端问题，也可能是Broker自身资源耗尽导致断连。
  • "Too many messages in backlog": 直接显示主题积压严重。

2. BookKeeper 节点排查

BookKeeper是Pulsar的持久化存储层，消息的可靠性直接依赖于它。消息丢失或积压很多时候源于BookKeeper的读写性能瓶颈或可靠性问题。

• 指标监控：
  • bookkeeper_disk_usage_bytes / bookkeeper_journal_write_bytes / bookkeeper_entry_log_write_bytes：磁盘空间是否充足，I/O是否达到瓶颈。
  • bookkeeper_journal_sync_latency_micros / bookkeeper_ledger_write_latency_micros：Journal同步和Ledger写入延迟，高延迟意味着存储性能不佳。
  • bookkeeper_network_bytes_in_total / bookkeeper_network_bytes_out_total：网络I/O是否正常。
  • bookkeeper_num_open_ledgers：开启的Ledger数量是否过多。
  • bookkeeper_gc_time_seconds_total：JVM GC情况。
• 日志分析 (定位关键词)：
  • Bookie.java / Journal.java / EntryLogManager.java 相关日志：查找 disk full, I/O error, sync failed, timeout writing to journal, no space left on device, quorum error, replica pending for too long 等关键字。
  • "Journal write failed" / "EntryLog write failed": 磁盘I/O瓶颈或磁盘损坏。
  • "Not enough bookies available" / "Quorum not met": Bookie节点故障或网络隔离，导致无法完成副本写入。
  • "Force close ledger": Ledger被强制关闭，可能导致消息部分丢失或不可读。

3. ZooKeeper 节点排查

ZooKeeper为Pulsar提供元数据管理、协调和配置服务。ZooKeeper的异常可能导致集群不稳定、服务发现失败、甚至整个集群不可用。

• 指标监控：
  • zk_avg_latency / zk_max_latency：ZooKeeper请求延迟，高延迟会影响所有依赖组件。
  • zk_num_alive_connections：连接数是否正常。
  • zk_packets_sent_total / zk_packets_received_total：网络流量。
  • zk_outstanding_requests：待处理请求数，过高可能表明ZooKeeper过载。
• 日志分析 (定位关键词)：
  • 查找 session expired, connection loss, leader election failed, no quorum, zxid 相关的日志。
  • "Session expired"： Broker或BookKeeper与ZooKeeper失去连接，可能导致服务注册失败或不可用。
  • "No quorum": ZooKeeper集群多数节点不可用，集群将无法提供服务。
  • "Follower received an out of date zxid": 数据同步问题。

4. 客户端行为排查

很多时候，消息积压或丢失并非集群本身故障，而是客户端使用不当。

• Producer端：
  • 配置不当： sendTimeoutMs 过短导致频繁超时重试，或者消息批量发送（batching）配置不合理（过大导致延迟高，过小导致吞吐量低）。
  • 阻塞发送： 生产者同步发送但未处理发送失败异常。
  • 消息体过大： 导致网络传输和Broker/BookKeeper处理压力。
  • 网络问题： 客户端与Broker之间网络不稳或带宽不足。
• Consumer端：
  • 消费逻辑阻塞： 业务逻辑处理时间过长，未及时 ack 消息，导致消息在Broker端堆积。
  • receiverQueueSize 过小： 消费者拉取消息的本地队列太小，无法充分利用并行处理能力。
  • ackTimeoutMillis 配置不当： 消息未在规定时间内被确认，导致Broker重发。
  • 订阅模式与类型： 共享订阅模式下，部分消费者宕机或处理能力弱，可能导致积压。独占订阅模式下，消费者宕机直接导致消费中断。
  • 重复消费： 消息丢失后，如果客户端手动 seek 或 reset 订阅位置，可能导致重复消费。
  • 网络问题： 消费者与Broker之间网络不稳。
• 区分方法：
  • 观察客户端日志： 生产端是否存在大量的 SendTimeoutException，消费端是否存在 NegativeAcks 或长时间未 Ack 的警告。
  • 检查客户端应用资源： 客户端应用程序的CPU、内存、网络I/O是否饱和。
  • 对比集群和客户端： 如果集群指标正常，但特定客户端出现问题，则很可能是客户端问题。如果集群多个组件出现异常，且影响面广，则指向集群内部故障。

三、实践建议

1. 分层监控： 建立覆盖Pulsar所有组件（Broker, BookKeeper, ZooKeeper）以及客户端的完整监控体系。
2. 日志聚合： 使用ELK或Loki等工具聚合所有日志，便于快速搜索和关联分析。
3. 灰度发布与配置管理： 对客户端配置和集群配置的任何变更，都应进行灰度发布并有回滚方案。
4. 压力测试： 在上线前对Pulsar集群进行充分的压力测试，模拟生产环境负载。

通过上述多维度、系统化的排查方法，结合Pulsar特有的日志线索和内部状态，我们能更高效地定位消息积压或丢失的根本原因，并采取针对性措施解决问题。