ZooKeeper学习总结

• 从设计模式理解：基于观察者模式设计的分布式服务管理框架。（文件系统+通知机制）
• 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：内部选举用的端口