Pulsar 作为下一代云原生分布式消息与流处理平台，凭借其高吞吐、低延迟、强一致性和高度可扩展 的架构设计场外配资网站，已在全球范围内被众多头部企业广泛采用为关键基础设施。自成为 Apache 顶级项目以来，Pulsar 经历了大规模生产环境的充分验证，尤其适用于云原生部署环境，支持多租户、弹性扩缩容和无缝容器化集成。然而，其精密而先进的架构在带来强大功能的同时，也增加了系统操作与问题定位的复杂性。
谙流科技自 Pulsar 项目早期阶段便深度参与其生态建设，核心团队在 Apache Pulsar 和 Apache BookKeeper 的研发、运维与优化方面积累了丰富的实战经验。凭借对 Pulsar 底层机制的深刻理解，团队积累了深厚的实践经验，能够高效应对各类复杂场景下的技术挑战。
问题诊断
问题：Consumer 消息拉取故障、机架感知 Bookies 节点数不足；集群网络连接超时，导致集群严重无法使用。
诊断 ：跨区域（下文简称为跨 AZ）的 Pulsar 集群网络问题的根本原因是防火墙较短的探活周期断开了 Pulsar 和 BookKeeper 的 TCP 连接。
展开剩余71%TCP 保活（TCP keepalive）
TCP 双方建立连接后，如果长时间无数据交互，且不主动释放连接，或出现掉电等意外情况时，连接的另一方将始终维护这些无效的连接。长期积累，会导致大量半连接出现。这给对端系统造成了大量资源浪费。通常会在传输层使用 TCP 保活机制来解决这个问题。
防火墙超时灭活
防火墙等中间设备会维持连接信息表，并设有超时删除机制。如果有连接在定时器探活期间发现无数据保活交互，则会将连接从中删除。
删除后的表现为，应用认为仍然连接着服务（实际连着防火墙），防火墙并未断连，只是删除了自行维护的链接信息表。当应用再有新的报文发来时，防火墙会直接丢弃该报文，从而导致应用出现 RST 等异常网络表现。
防火墙的 "超时灭活" 机制，会给需要长连接，但可能长时间无数据交互的应用（如数据库和消息队列）带来极大影响。
Pulsar 作为底层核心消息队列，通常处于没有防火墙的内网环境中。因此相关报错处理，外界的经验会相对较少。同时，Pulsar 的消息处理场景，典型场景为高吞吐、低延时的核心消息处理，其长连接通常处于数据满载的状态。因此，长时间维持连接但无数据交互的罕见场景也触及了 Pulsar 应用的边界，这块经验也相对较少，同样会给问题定位带来麻烦。
Pulsar 的保活机制
Pulsar 的 TCP 连接主要分为两类：
PulsarBroker 和 PulsarClient 的客户端侧连接，采用主动 Ping-Pong 保活机制，默认 30 秒。
PulsarBroker 和 Bookie 的内部连接，如果没有特别设置，默认值通常是操作系统的默认值（例如，在 Linux 上通常是 7200 秒，即 2 小时）。
当 Pulsar 集群有大量连接、但较多连接长时间无数据交互的情况下，且默认保活时间小于防火墙的保活时间，则比如会被防火墙的保活机制给灭端连接，造成网络 Reset 和超时等问题。大量的网络问题会引发集群内部未知的其他问题。
在用户实际的网络中，Broker-Bookie 间采用操作系统级别的 TCP 连接保活机制，默认 2 小时探活一次，而跨 AZ 的防火墙探活检测为 20 分钟，因此触发网络异常问题。
发布于：湖南省领航优配提示：文章来自网络，不代表本站观点。
