构建下一代万亿级云原生消息架构：Apache Pulsar 在 vivo 的探索与实践( 五 ) 作者|陈建波、全利民本文整理

文章图片
图15.1个Topic、120个分区、180个Bundle的每秒入流量

文章图片
图16.1个Topic、120个分区、180个Bundle下， Bundle上Topic分区情况

文章图片
图17.1个Topic、120个分区、180个Bundle的入流量分布
客户端发送性能
在和上述业务相同的场景中，分区数量增加后，系统滚动重启后出现了流量下降情况：

文章图片
图18.单个Topic ， 30个分区增加到120个，系统滚动重启后流量下降
客户端配置参数：maxPendingMessages=2000（默认1000）maxPendingMessagesAcrossPartitions=40000（默认50000）batchingMaxPublishDelayMicros=50（默认1毫秒）batchingMaxMessages=2000（默认1000）
满足三个batch数据中的任何一个的情况下就会触发打包、发送。

文章图片
图19.重启后maxPendingMessages（队列长度）出现下降
这里maxPendingMessages（队列长度）=min(maxPendingMessages,maxPendingMessagesAcrossPartitions/partitionNum) 。而分区数添加（30->120）后，需要重启客户端才对队列长度生效。重启后maxPendingMessages队列长度从40000/30=1333变为40000/120=333 ，出现了明显下降。
另外，测试发现batchingMaxMessages调小后性能提升10倍之多：

文章图片
图20.单个Topic ， 30个分区增加到120个，调整后性能提升
建议batchingMaxPublishDelayMicros不要过大，确保batchingMaxMessages比maxPendingMessages要大，否则等待batchingMaxPublishDelayMicros才会发送。
宕机导致集群流量骤降
某个分区队列满后会导致发送线程阻塞，影响所有分区的整体发送和集群稳定性：

文章图片
图21.执行Kill-9一台Broker后，其他Broker流量下降
图22.第四个分区已满，发送线程阻塞在canEnqueRequest上，等待时间长，其他未满分区的发送也被影响。

文章图片
图23.极端情况下，第四个分区已满，其他分区等待中。发送线程会在第四个分区阻塞等待，其他线程无法发送。
针对这一问题的优化思路，首先是能者多劳，让发送快的分区尽可能多发送；然后是将阻塞点从ProducerImpl移到PartitionedProducerImpl；如果分区ProducerImpl出现队列已满阻塞较长时间，就将该分区排除。

文章图片
图24.宕机导致集群流量骤降优化思路
实践中可分为可用Producer和不可用Producer两个列表。在①中，两个列表都处于初始化状态并可用；在②中，某个可用分区阻塞一段时间后可以等待一段时间；若不可用就移动到不可用列表中，如③所示；当分区可用比例达到阈值再挪回可用列表，如④所示。
经过优化后，宕机Broker流量可以快速转移到其他Broker：

文章图片
图25.优化后Broker流量分流并上涨
注：优化只支持RoundRobinPartitionMessageRouterImpl路由策略。
在单个ProducerImpl对应的Broker出现处理慢、网络慢等导致发送响应慢的情况，都可能会导致发送线程阻塞，业务发送消息的速度受限于最慢的ProducerImpl的速度。