zookeeper

ZooKeeper是分布式协调服务，解决分布式系统的配置管理、服务发现、分布式锁等核心问题。设计目标追求简单性、可靠性、高性能，提供统一命名空间和顺序一致性保证。

ZooKeeper数据模型采用层级命名空间，ZNode节点存储数据和子节点。版本号包括dataVersion、cversion、aversion用于乐观锁。集群角色Leader处理写请求、Follower处理读请求和投票、Observer扩展读能力。

ZooKeeper安装需JDK环境，下载解压后配置zoo.cfg文件。单机模式设置dataDir数据目录、clientPort客户端端口，tickTime心跳时间单位。启动使用zkServer.sh脚本。

ZooKeeper集群部署需配置多节点地址列表、myid文件标识节点身份。集群至少3节点保证过半存活。使用zkServer.sh启动各节点，stat命令查看Leader/Follower角色。生产环境建议奇数节点部署。

ZooKeeper节点类型包括持久节点（永久存在）、临时节点（会话结束删除）、顺序节点（自动编号）。临时节点适合服务注册，顺序节点适合分布式锁和唯一ID生成。组合类型如临时顺序节点实现公平锁。

ZooKeeper节点操作命令包括create创建节点、get读取数据、set修改数据、delete删除节点。ls命令查看子节点列表，ls2包含状态信息。节点路径必须以/开头，操作需注意版本号和权限。

ZooKeeper命令行客户端zkCli.sh连接服务器，支持超时参数配置。常用命令包括ls查看节点、get读取数据、create创建节点、set修改数据、delete删除节点。quit退出客户端，history查看历史命令。

ZooKeeper ACL权限模型包含权限位(crwda)和认证方案。权限位包括create、read、write、delete、admin。认证方案有world(开放)、auth(已认证)、digest(密码)、ip(IP限制)。节点可设置ACL限制访问。

ZooKeeper集群要求奇数节点（3、5、7），过半节点存活即可服务。Leader选举基于过半投票机制，ZXID最大者优先。选举触发条件包括集群启动和Leader宕机。过半机制保证数据一致性。

ZooKeeper集群数据同步通过Leader向Follower发送提议，过半确认后提交。Observer不参与投票只同步数据。集群状态检测使用stat、mntr四字命令查看Leader状态、ZXID、连接数等关键信息。

ZooKeeper会话包含创建、心跳检测、超时失效、临时节点清理四个阶段。会话状态包括CONNECTING、CONNECTED、SUSPENDED、RECONNECTED、LOST。客户端需监听状态变化处理重连和临时节点重建。

ZooKeeper Watcher是一次性触发机制，触发后需重新注册。事件类型包括节点创建、删除、数据变更、子节点变更。数据监听用getData、子节点监听用getChildren。Curator的TreeCache解决一次性问题。

ZooKeeper使用FastLeaderElection算法进行Leader选举，投票规则为ZXID最大者优先、myid次优。选举配置参数initLimit控制初始化超时、syncLimit控制心跳同步。选举触发于集群启动或Leader宕机。

Follower处理读请求、转发写请求、参与投票。Observer不参与投票只处理读请求，适合跨地域部署。动态扩缩容需修改配置文件、创建myid、重启集群。Observer可动态添加无需重新选举。

ZAB协议是ZooKeeper原子广播协议，保证消息原子性和顺序性。消息广播采用两阶段提交：Leader发送提议、Follower发送ACK、过半确认后提交。所有消息全局有序，ZXID保证顺序一致性。

ZooKeeper崩溃恢复流程包括Leader选举、数据同步、Epoch更新。ZXID高32位是Epoch纪元，低32位是计数器。新LeaderEpoch必须大于旧Epoch，保证数据一致性。恢复使用DIFF/TRUNC/SNAP同步数据。

ZooKeeper保证顺序一致性：客户端请求按序执行、FIFO顺序、全局事务序。写请求链路从客户端→Leader→Follower→过半确认→提交→响应。Leader处理所有写请求，保证全局一致。

ZooKeeper分布式锁使用临时顺序节点实现。排他锁竞争创建临时节点，公平锁监听前一个节点避免羊群效应。读写锁用read-/write-前缀区分，读锁可共享，写锁互斥。临时节点保证宕机自动释放。

ZooKeeper分布式屏障使用节点计数等待所有参与者到达。双屏障有进入和离开两个阶段。锁超时使用acquire(timeout)设置，超时返回false。锁释放通过删除节点或会话超时自动删除临时节点。

ZooKeeper配置中心使用节点存储配置数据，路径设计按应用分组。配置变更推送通过Watcher监听NodeDataChanged事件，触发后重新读取配置并更新本地缓存。推送实时性好，适合动态配置场景。

ZooKeeper配置版本管理使用节点version字段实现乐观锁和版本控制。多环境配置隔离使用不同路径如/config/dev、/config/prod。环境继承通过公共配置和环境特定配置合并实现。生产环境配置需设置ACL保护。

ZooKeeper服务注册发现使用临时节点存储服务地址。服务提供者创建临时节点注册地址，消费者获取子节点列表发现服务。临时节点绑定会话，服务宕机自动注销。Watcher监听实现实时服务列表更新。

消费者缓存服务地址列表，Watcher监听变更时惰性更新。服务分组按版本或区域划分，支持灰度发布路由。分布式唯一ID使用顺序节点生成，序号作为全局唯一标识，10位数字约21亿范围。

ZooKeeper监控使用四字命令（stat、mntr、cons、ruok）快速查看状态。JMX提供详细指标如PacketsReceived、AvgRequestLatency、NumAliveConnections。监控工具包括JConsole、VisualVM、Prometheus JMX Exporter。

ZooKeeper事务日志在dataDir/version-2目录，使用LogFormatter工具分析。快照保存某一时刻数据状态，事务日志记录写操作。健康检查关注Leader状态、ZXID一致性、延迟和连接数。定期清理避免磁盘满。

Curator是ZooKeeper高级客户端框架，简化API、自动重连、内置重试策略。异常处理区分ConnectionLoss（等待重连）和SessionExpired（重建客户端）。Recipes提供分布式锁、选举、屏障、TreeCache等配方实现。

ZAB协议源码核心类包括LeaderZooKeeperServer、FollowerZooKeeperServer、LearnerHandler。Leader请求处理链：PrepRequestProcessor→ProposalRequestProcessor→CommitProcessor→FinalRequestProcessor。两阶段提交异步化、流水线、批处理优化吞吐。

ZAB消息队列包含发送队列和接收队列，支持批处理和流水线。Epoch纪元每次选举递增，保证新Leader提议优先。Follower数据同步有DIFF（差异）、TRUNC（截断）、SNAP（快照）三种方式，根据ZXID差距选择。

JVM内存调优根据节点数据量配置堆内存，G1 GC适合低延迟场景。磁盘IO优化关键是将事务日志与快照分离存储到不同磁盘，使用SSD提升写入性能，调整IO调度策略为deadline。

网络参数tickTime、syncLimit、initLimit适配网络延迟。maxClientCnxns限制单IP连接数。快照优化配置snapCount和autopurge自动清理。容量规划根据QPS、节点数、会话数评估集群规模，写QPS是瓶颈指标。

Leader宕机恢复流程：Follower检测心跳超时→发起选举→选出新Leader→数据同步→恢复服务。网络分区脑裂由过半机制防止，少数派无法选出Leader。恢复步骤：修复网络、确认合法Leader、重启少数派节点。

数据不一致类型包括事务丢失（ZXID落后）和脏数据（未提交提议）。使用txnlog工具分析事务日志定位差异。修复流程：分析日志→确认正确版本→TRUNC截断或手动修复。磁盘损坏恢复从健康节点复制快照或清空目录触发SNAP同步。

性能瓶颈诊断使用JConsole、VisualVM、top/iotop定位CPU、内存、IO瓶颈。高延迟检查磁盘IO，GC频繁检查内存，连接拒绝检查连接数。事故复盘流程：收集时间线→分析根因→制定改进措施→落实预防。

SASL认证支持Kerberos企业级认证和DIGEST-MD5密码认证。Kerberos需配置JAAS文件、keytab文件、KDC服务。SSL/TLS加密配置服务端和客户端证书，使用secureClientPort端口。生产环境建议禁用普通端口，只开放SSL端口。

IP白名单通过防火墙或IP认证方案限制访问。企业级ACL设计按角色分层：管理员、服务提供者、消费者。敏感节点设置digest ACL，公开节点限制权限。审计日志记录所有操作，追踪敏感访问行为。

多集群联邦架构实现跨数据中心负载均衡，联邦路由层按数据中心路由请求、同步数据。同城双活架构两地互备，故障自动切换。异地灾备架构主集群→备集群数据同步，故障时备集群升级为主。同步延迟影响数据一致性。

Observer不参与投票，可无限扩展读能力，适合跨地域部署。集群分层架构按系统层、业务层、租户层隔离，ACL控制权限边界。读写分离策略：写请求发Leader，读请求分散到Follower/Observer，就近访问降低延迟。

Kafka用ZooKeeper管理Broker注册和Controller选举，Kafka 2.8+支持KRaft模式逐步移除依赖。HBase用ZooKeeper做Master选举和Region定位。Dubbo用ZooKeeper做服务注册发现。Spring Cloud Zookeeper实现服务发现和配置中心。

ZooKeeper替代方案包括etcd（Kubernetes首选）、Consul（服务发现+健康检查）、Nacos（服务发现+配置）、Eureka（AWS友好）。对比维度：CP模型、服务发现、配置中心、健康检查、API复杂度。迁移需评估生态依赖和改造成本。