本文转载自公众号：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 中，不会被删除，因而在生产环境中应用的时候必须留神。
Image

当 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 无奈开释存储空间的解决办法，心愿对你有所帮忙。

相干浏览