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

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

关于 Apache Pulsar

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

GitHub 地址：http://github.com/apache/pulsar/

对于初学 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 无法释放存储空间的解决方法，希望对你有所帮助。