目录
(1).pulsar生产集群规模
(2).集群磁盘爆炸原因与解决
1.磁盘爆炸原因
2.恢复集群
3.解决方式
(1).pulsar生产集群规模
生产环境集群（为了省钱是一个最小集群）：
在aws上部署了3台8c16g的pulsar集群。选择的是1:2的c系列机型：c5a.2xlarge。
每台节点放3个进程：zk, broker, bookie。
磁盘是400G/node，一共是1.2T，但是副本数是2，所以可以存放600G的消息。
(2).集群磁盘爆炸原因与解决
1.磁盘爆炸原因
在进行全链路压测时出现磁盘爆炸的情况，3个node的磁盘使用率都超过了95%。
经过调查是因为实时计算flink中的pulsar-flink-connect使用的topic的订阅者出现了2、3亿条的消息堆积（一共12个分区，每个分区的backlog都是2、3千万）。
原因：
是pulsar-flink所创建/使用/管理的订阅者（reader）的markDeletePosition和readPosition不相等，value(markDeletePosition) << value(readPosition)，每个都差2、3千万。查看官方issue这里存在这种情况，貌似后续版本会解决。
2.恢复集群
通过设置过期时间1s（单位是秒），让pulsar自动删除过期ledgers。
注意这里我设置1秒是因为业务是内测阶段所以可以，生产这么设你可以跑路了！！！
bin/pulsar-admin namespaces set-message-ttl xxx/public --messageTTL 1
重启每个bookie。
bin/pulsar-daemon stop bookie
bin/pulsar-daemon start bookie
恢复TTL配置：
bin/pulsar-admin namespaces remove-message-ttl xxx/public
再次get是：null
bin/pulsar-admin namespaces get-message-ttl xxx/public
bookie是每隔15分钟做一次清理，所以还是很麻烦，要做好监控/报警。
注意：
pulsar的消息ttl设置只能在namespace这一个级别进行设置。
3.解决方式
四处盘也没有找到优雅的解决方式，最后用一种工程方法去解决：
pulsar-flink-connector用到的topic放到一个单独的namespace，然后对这个space进行ttl设置（1小时），这样来保证它的backlog不会爆炸。一定要和相关业务放进行确认！
创建namespace:
bin/pulsar-admin namespaces create xxx/flink
bin/pulsar-admin namespaces set-message-ttl xxx/flink --messageTTL 3600
然后创建topic即可：
/app/3rd/apache-pulsar-2.8.0/bin/pulsar-admin topics create-partitioned-topic -p 12 persistent://xxx/flink/topic
处理完后也得到了pulsar官方的回复（pulsar官方还是很给力的），并且在相关issue中看到类似问题和解决方式：目前也是这么通过ttl处理。
