Apache Pulsar 中非持久化游标关闭时的异常日志问题分析

问题背景

在 Apache Pulsar 的消息消费机制中，Reader 是一种特殊的消费者模式，它允许用户从指定位置开始顺序读取消息。近期在 Pulsar 的 master 分支中发现了一个关于非持久化游标(NonDurableCursor)的错误日志问题，虽然不影响功能正常运作，但会产生令人困惑的 ERROR 级别日志。

问题现象

当使用 Reader 读取消息并立即关闭时，系统会记录以下错误日志：

Error reading entries at 5:1 : Cursor was already closed - Retrying to read in 1.0 seconds

随后又记录：

Skipping read retry: Current Consumer null, havePendingRead false

这些错误日志出现在正常的操作流程中，实际上系统行为是正确的，但日志输出会给运维人员带来不必要的困扰。

技术原理分析

非持久化游标的工作机制

非持久化游标是 Pulsar 中为 Reader 设计的一种特殊游标，它不会持久化消费位置。在内部实现上，ManagedCursorImpl 类负责管理游标的读取行为。

问题根源

问题的根本原因在于消费流程中的时序问题：

1. 当 Reader 执行 readNext() 然后立即关闭时
2. 如果此时 hasMoreEntries() 返回 false，系统会进入 checkForNewEntries() 流程，默认带有 10ms 的延迟
3. 在这 10ms 延迟期间，非持久化游标的状态变为已关闭
4. 延迟结束后，checkForNewEntries() 会抛出 CursorAlreadyClosedException

相关代码逻辑

在 ManagedCursorImpl 类中，关键的读取逻辑包括：

• asyncReadEntriesWithSkipOrWait 方法：发起异步读取
• 游标关闭操作：将游标状态标记为已关闭
• 延迟后的 checkForNewEntries 检查：此时会因游标已关闭而抛出异常

影响评估

这个问题本质上是一个日志记录问题，不会影响系统功能的正确性：

• 消息消费和 Reader 关闭都能正常完成
• 不会导致数据丢失或重复消费
• 不会影响系统稳定性

但错误日志会给运维监控带来干扰，可能导致不必要的告警和排查工作。

解决方案

针对这个问题，合理的修复方向应包括：

1. 在游标已关闭的情况下，不应再记录错误日志
2. 当检测到游标已关闭时，应取消后续的读取调度
3. 需要统一考虑持久化和非持久化游标在此场景下的处理逻辑

最佳实践建议

对于使用 Pulsar Reader 的开发者，建议：

1. 合理控制 Reader 的生命周期，避免频繁创建和关闭
2. 在监控系统中可以过滤这类已知的正常错误日志
3. 关注 Pulsar 的版本更新，及时应用相关修复

总结

这个问题展示了分布式系统中时序敏感操作的复杂性，即使是正确的业务逻辑也可能因为内部组件的状态变化时序而产生令人困惑的现象。通过深入分析游标管理机制和读取流程，我们能够理解并解决这类日志问题，提升系统的可观测性。