Apache Pulsar 4.0.2版本中时间戳定位功能的异常行为分析

在Apache Pulsar 4.0.2版本中，用户报告了一个关于消息订阅位置重置的严重问题。该问题主要影响使用时间戳定位（seek by timestamp）功能的场景，会导致订阅位置意外重置到主题的最早消息位置，而非预期的目标时间戳后的第一条消息位置。

问题现象

当用户尝试通过指定时间戳来定位消息时，系统本应将订阅位置重置到该时间戳之后的第一条可用消息。然而在4.0.2版本中，实际操作结果却是将订阅位置重置到了主题的最早消息位置。这种异常行为会严重影响消息消费的正确性和顺序性。

问题根源

经过技术团队分析，该问题源于4.0.2版本中引入的一个新功能变更。这个变更原本是为了处理账本关闭时间戳与系统时钟偏差的问题，但在实现过程中意外影响了时间戳定位功能的正常逻辑。

具体来说，新功能在处理时间戳比较时采用了过于激进的策略，导致在某些情况下错误地将订阅位置重置到了最早位置。这个问题在4.0.1版本中并不存在，进一步验证了这是4.0.2版本引入的回归问题。

临时解决方案

对于必须使用4.0.2版本的用户，技术团队提供了以下临时解决方案：

可以通过设置特定的配置参数来禁用引起问题的功能：

managedLedgerCursorResetLedgerCloseTimestampMaxClockSkewMillis=-1

对于Kubernetes环境下的部署，可以在配置中添加：

broker:
  configData:
    PULSAR_PREFIX_managedLedgerCursorResetLedgerCloseTimestampMaxClockSkewMillis: "-1"

技术建议

对于生产环境中的用户，建议采取以下措施：

1. 如果尚未升级到4.0.2版本，建议暂缓升级
2. 如果已经升级并遇到此问题，应立即应用上述临时解决方案
3. 密切关注后续版本更新，及时应用官方修复补丁

总结

这个问题提醒我们在使用消息中间件时需要注意版本变更可能带来的行为变化。特别是在生产环境中升级前，应该充分测试关键功能是否正常工作。对于时间戳定位这种精确控制消费位置的功能，更应该进行专项验证。

Apache Pulsar团队已经将该问题记录在4.0.2版本的发布说明中，并承诺在后续版本中提供永久修复方案。用户社区可以期待在下一个维护版本中看到这个问题的彻底解决。