CentOS环境下ZooKeeper性能瓶颈分析与优化策略
存储I/O性能不足：ZooKeeper的数据写入（事务日志、快照）高度依赖磁盘I/O，传统机械硬盘（HDD）的高延迟、低吞吐量会成为核心瓶颈。
CPU资源不足：Leader节点处理客户端请求、follower节点同步数据时，多线程并发操作需要足够的CPU核心支撑，CPU过载会导致请求排队。
内存资源不足：ZooKeeper将热点数据（如会话信息、最近的事务日志）缓存在内存中，内存不足会迫使系统频繁读取磁盘，大幅提升延迟。
资源竞争：与Kafka、Redis等资源密集型应用共用服务器，导致CPU、内存、I/O资源被抢占，影响ZooKeeper性能。
Swap分区启用：当物理内存不足时，系统会将内存数据交换到Swap分区（磁盘），导致ZooKeeper处理请求时出现磁盘I/O瓶颈，显著增加延迟甚至崩溃。
文件描述符限制过低：ZooKeeper处理大量客户端连接时，每个连接都会占用文件描述符，若系统限制（默认通常为1024）过低，会导致无法接受新连接或报“Too many open files”错误。
内核参数未优化：如net.core.somaxconn（监听队列长度）默认值较小（通常为128），高并发场景下会导致连接请求被拒绝；vm.swappiness（Swap倾向）默认值较高（通常为60），会过早触发Swap。
tickTime设置不合理：tickTime是ZooKeeper的基本时间单位（默认2000毫秒），用于心跳检测、会话超时等计算。若设置过小，会增加不必要的网络通信；若设置过大，会导致会话超时时间过长，无法及时检测故障节点。
initLimit/syncLimit设置不当：initLimit是Leader与Follower初始连接的超时时间（默认10tickTime），若集群节点间网络延迟高，设置过小会导致初始化失败；syncLimit是Leader与Follower同步数据的超时时间（默认5tickTime），若设置过大，会延长同步时间，影响数据一致性。
maxClientCnxns未限制：默认情况下，ZooKeeper不限制单个客户端的连接数，若某个客户端异常（如死循环创建连接），会占用大量资源，导致其他客户端无法正常访问。
dataDir/dataLogDir未分离：事务日志（dataLogDir）和快照文件（dataDir）默认存放在同一目录，两者都是高频写入操作，会竞争磁盘I/O资源，降低写入性能。
自动清理未开启：若未开启autopurge.snapRetainCount（保留快照数量，默认3）和autopurge.purgeInterval（清理间隔，默认0，不开启），旧的事务日志和快照会不断累积，占用大量磁盘空间，甚至导致磁盘满，影响ZooKeeper运行。
堆内存设置不合理：JVM堆内存过小（如不足1GB），会导致频繁的Young GC，增加延迟；若堆内存过大（如超过8GB），会导致Full GC时间过长（可达秒级），期间ZooKeeper无法处理请求。
垃圾收集器选择不当：默认的Serial GC（串行收集器）在多核CPU环境下效率低下，无法满足ZooKeeper的高并发需求；若使用CMS GC（并发收集器），虽然能减少停顿时间，但在高负载下仍可能出现“Concurrent Mode Failure”，触发Full GC。
节点间网络延迟高：ZooKeeper集群的Leader与Follower之间需要频繁通信（如心跳、同步数据），若节点间网络延迟过高（如超过100ms），会导致同步超时、请求处理缓慢。
带宽不足：大量客户端同时发送写请求时，会产生大量网络流量，若带宽不足（如100Mbps以下），会导致请求排队，增加延迟。
网络丢包：网络丢包会导致重传，增加请求处理时间，严重时会导致连接中断。
节点数量不足：ZooKeeper集群的性能与节点数量呈线性关系（通常3-5个节点即可满足大多数场景），若节点数量过少（如1个节点），无法发挥集群的高可用和高性能优势；若节点数量过多（如超过7个），会增加Leader选举的时间和复杂度。
数据分片缺失：对于存储大量数据（如超过10TB）的集群，未进行数据分片会导致单个节点负载过高，影响整体性能。