- 从设计模式理解：基于观察者模式设计的分布式服务管理框架。（文件系统+通知机制）
- Zookeeper本身是一个集群：有一个leader和多个follower,半数已上的节点存活就可以工作
- 特点
- 数据全局一致。每个节点存储一份数据，每个节点数据都已是。CAP中的CP
- 同一个Client的更新请求顺序执行。
- 数据更新原子性，一次更新要么成功要么失败。
- 实时性，在一定时间内能读取到最新数据，同步非常之快
- 应用场景，提供以下服务：
- 统一命名服务（注册中心）
- 统一配置管理（配置中心）
- 统一集群管理（选举、节点实时变化监控）
- 服务器上下线通知（观察者模式，通知中心）
- 软负载均衡（命名服务记录地址访问次数，让访问次数最少的地址提供服务）
- 配置参数
- tickTime 心跳帧，每隔2s心跳一次
- initLimit 启动时leader和follower 最长心跳间隔，10个心跳
- syncLimit 启动后leader和follower 最长心跳间隔，5个心跳
- 内部原理
- 内部选举机制：半数机制，每个人上线后先投票自己，不行后，投票id号最大的。超过半数后成为leader。有leader后后续上线节点不再投票选举。
- 节点类型：持久(Persistent)/短暂(Ephemeral)
- 持久节点：端开连接后依然存在。
- 持久顺序编号目录节点：Zookeeper可以对该节点名称及进行顺序编号，顺序编号由夫节点维护，单调递增。使用场景：可以通过编号对全局事件进行排序，客户端可以通过数序编号推断事件的顺序
- 临时节点：端开后被删除
- 临时顺序编号目录节点：端开后被删除，知识给该节点进行顺序编号
- 监听器的原理
- main线程初始化zkclient时，创建connect和listen两个线程，connect负责注册监听事件，listen负责接收监听，并调用业务process方法。
- 写数据流程
- client -->server1-->转发leader--->广播server-->各个server-->返回写结果-->超过一半写成功-->leader发送结果给-->server1-->client
- 实战（最少3台）
- zkData中添加myid文件
- conf/zoo.cfg 添加 server.A=B:C:D
- A：myid中数字
- B： 主机域名或者IP
- C：Leader与Follower之间数据通信端口
- D：内部选举用的端口