用户有些应用处理非常耗时，对于单条消息的处理，通常保持在 8~9 分钟。在未改版之前，应用逻辑为每条消息对应一个消费者处理，使用多个 Consumer 通过 Shared 订阅来提升处理性能。
多个 Consumer 隶属于一个客户端，每个客户端会和 Pulsar 集群建立一个 TCP 连接。代码中消费结束后并未发现主动 close 掉客户端的动作。这些都将导致，随着并发处理数据消息量的增加和时间的累积，集群中的连接数量会过多（有小集群，保留有 7000 多客户端连接）。
这些应用的过慢处理，也会快速占满网络侧资源，同时也会加剧 "防火墙灭活" 机制的影响。
排查过程
问题暴露后
第 3 个工作日
远程协助集中排查问题。问题为跨 AZ 网络环境下集群连接出现各类报错，包括 Connection reset by peer 和 connection timed out 。网络抓包发现大量半连接满问题。建议调整 TCP 内核参数，重点将 net.core.somaxconn 从默认 128 调整到 1024 并复测。
第 4 个工作日
不间断远程支持。反馈调参复测后问题得到缓解，但仍有网络连接报错，且伴随大量其他报错。大量报错干扰排查，让问题追踪陷入困境，谙流要求保持单 AZ 环境排查，一直等待实施中。由于当日问题仍未解决，升级响应，希望有专家入场排查。
第 5 个工作日
谙流支持入场并会同远程排查。经反复测试，确定问题为跨 AZ 网段的网络 "保活问题"，现象为单 AZ 集群各类测试无误，跨 AZ 抓包发现大量 FIN 包丢失，即 Pulsar 连接被防火墙 "架空"，防火墙默认断开超过 20 分钟无保活连接。而 Pulsar-Bookie 默认采用 OS 保活机制（默认 2 小时），因此出现网络连接问题，怀疑此为根因。谙流人员出场，建议次日用户陪同防火墙专家复测。
第 6 个工作日
远程不间断支持。用户复测抓包确认防火墙关闭了 Broker-Bookie 的连接，确认了防火墙保活超时关闭机制。谙流确认 Pulsar-Bookie 依赖 OS 保活策略，基本确认根因，等待用户修改保活配置，复测确认根因。
第 9 日
远程不间断支持。用户修改保活参数，发现起 "反向" 作用，且由于影响应用测试，又回退保活配置，确认测试陷入僵局。谙流要求搭建自测多 AZ 集群（应用前期不参与测试）。同时期，审核代码，并应用调整代码实现，使用缓存方式，去除一个消息新建一个客户端的实现。
第 10 日
远程不间断支持。用户通过降低 Broker-Bookie 的保活为 15 分钟，在自测多 AZ 集群复测，无报错，邀请应用复测，无报错。确定根因。
