深入理解zookeeper

1. 什么是zookeeper

zookeeper是一个独立的分布式框架

• zookeeper = 文件系统 + 监听同步机制

2. zookeeper的文件系统

• zookeeper中存在一个小型的文件系统。
• 作用：存大家都关心的数据
• 存在形式：
  树形结构存在，每个节点都是一个znode
  默认只有一个根节点(zookeeper)
  随着数据的增加，会不断壮大
• 数据的存在形式:
  在每个znode上以键值对的形式存在
  key:znode的名字 value:具体存储的内容

3. zookeeper选举机制

• 集群环境：
  可以独立有一个zookeeper集群，也可以在原有集群
  架构：主从架构
  角色：leader 和 follower
• 半数原则：
  在zookeeper的集群内只要有超过一半的节点可用，当前zookeeper集群就是可用的。
  启动时：只要到半数，集群就可用
  宕机时：只要剩余半数，集群不受影响
  a.所有节点全是follower，一切正常
  b.包含leader，重新选举leader
• 选举机制
  每个节点启动的时候先投自己一票，已启动的节点的id比自己小投自己一票(验证)，一旦启动的节点数量超过半数，集群可以运行，此时票数最多的节点就是leader，其余的全部都是follower。
• 思考：
  有10个节点，需要启动多少节点可以运行？
  有9个节点，需要启动多少节点可以运行？
• 结论：
  节点数量可以任意，但强烈建议使用奇数个节点
  

4. 监听同步机制原理实现

每个节点都有一个记录事件编号的位置，每个节点一旦监听到数据的变化，以当前时间编号加1进行提交给leader，leader进行验证，如果编号不冲突，同步给所有节点。如果某一时间多个节点同时提交事件，谁快就同步谁。
慢的那个直接被驳回，可以以下一个编号继续提交。
提交事件的状态要么成功，要么失败。

5. zookeeper节点类型

1. 持久：是用的最多的一种类型，也是默认的节点类型
2. 临时：临时节点相较于持久节点来说，就是它会随着客户端会话结束而被删除，通常可以用在一些特定的场景，例如分布式锁释放，健康检查等。
3. 持久顺序，临时顺序：这两种我放在一起介绍，因为他们相对于上面两种的特性就是 ZK 会自动在这两种节点之后增加一个数字的后缀，而路径 + 数字后缀是能保证唯一的，这数字后缀的应用场景可以实现诸如分布式队列，分布式公平锁等
4. 容器：容器节点是 3.5 以后新增的节点类型，只要在调用 create 方法时，指定 CreateMode 为 CONTAINER 即可创建容器的节点类型，容器节点的表现形式和持久节点是一样的，但是区别是 ZK 服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为 0 时，会自动删除该节点，除此之外和持久节点没有区别，官方注释给出的使用场景是 Container nodes are special purpose nodes useful for recipes such as leader, lock, etc. 说可以用在 leader 或者锁的场景中。
5. 持久 TTL，持久顺序 TTL：关于持久和顺序这两个关键字，不用我再解释了，这两种类型的节点重点是后面的 TTL，TTL 是 time to live 的缩写，指带有存活时间，简单来说就是当该节点下面没有子节点的话，超过了 TTL 指定时间后就会被自动删除，特性跟上面的容器节点很像，只是容器节点没有超时时间而已，但是 TTL 启用是需要额外的配置（这个之前也有提过）配置是 zookeeper.extendedTypesEnabled 需要配置成 true，否则的话创建 TTL 时会收到 Unimplemented 的报错