博文推荐|Pulsar 存储空间不释放的问题分析与解决方法

461

本文转载自公众号:StreamCloudNative,作者薛松,转载已获得作者许可。

关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
GitHub 地址:github.com/apache/puls…

对于初学 Pulsar 的人员,在使用 Pulsar 的时候经常会遇到 BookKeeper 存储空间无法释放的问题,本文就是针对这个问题做出一些定位和分析的思路,提供解决方法。

我们借助 pulsar-manager 的界面管理工具来分析消息存储不释放的问题,在 Cluster 菜单的 Bookies 页面中,可以看到 Bookies 集群的主机上,每台主机的磁盘利用率。 > Pulsar Topic 默认情况下,每个分区只会保存一个分段的存储空间(在没有订阅关系存在的情况下),每个分段的最大存储空间或记录数是在 broker.conf 中配置的,如下: managedLedgerMaxEntriesPerLedger=50000 managedLedgerMaxSizePerLedgerMbytes=2048

当发生存储空间不释放的时候,我们在 Topic 中查看是否有订阅关系,当有订阅关系存在的时候,没有 ack 的消息是不会被删除的,并且消息是以分段的方式存储的,如果一个分段中有一条消息没有 ack,那么这个消息所在的分段,以及之前所有的分段,都不会被删除,这也是Pulsar 与其它 MQ 差异的地方。

然后,我们查看订阅关系中的 Backlog,即积压量,是否一直没有减少的趋势,如果Pulsar 消费者应用已经下线,但订阅关系没有删除,那么新写入的消息会一直存储在 Bookie 中,不会被删除,因此在生产环境中使用的时候必须注意。

当 Topic 输入的速率比输出的速率快的时候,Backlog 可能会存在积压导致 Bookie 存储空间释放的慢,但是,如果 Backlog 积压量比较小,而 Bookie 的存储空间依然居高不下的时候,就可以查看 Topic 分区所占用的分段数,如下图所示,正常情况下,每个 Segment 列表应该只保留一个 Segment,如果同时存在多个 Segment,肯定是在Pulsar 的消费者这一侧出现了问题。 Pulsar BookKeeper 存储空间不释放的分析步骤,可以按照以下顺序执行:

  1. 查看 Topic 是否有消费者的订阅关系;
  2. 查看消费者的 Backlog 积压情况;
  3. 查看 Topic 分区占用的分段数,
  4. 分析消费者应用是否一直在执行 negativeAcknowledge 操作,或没有正常将消息执行 acknowledge 操作。

快速释放 Bookie 存储空间的方法如下:

  1. 在允许消息可丢失的情况下,手工清除订阅关系的 Backlog;
  2. 设置 TTL 策略,对于一定时间内不能被 acknowledge 确认的消息由 broker 自动提交;
  3. 使用死信和重试队列,对于一直无法 acknowledge 确认的消息,在重试 N 之后,将消息写入死信队列,输入消息不占用原 Topic 的存储空间;
  4. 在尝试以上步骤之后,依然无法释放存储空间的情况下,滚动重启 Bookie。

总结

Pulsar 的计算与存储分离的架构,让集群服务可以快速的水平扩展,但在使用上,与其它的 MQ 存在一定的差异,本文介绍 BookKeeper 无法释放存储空间的解决方法,希望对你有所帮助。