zookeeper-1

zookeeper=文件系统+监听通知机制， 分布式协调，分布式数据一致性解决方案

目录项如NameService称为znode(目录节点)，znode和普通目录不同的是可以存储数据，且存储在内存中
znode分可持久化/临时（客户端会话失效被删除），是否带顺序编号（父节点会给此节点名后追加一自增数字）分为四类
客户端和某Server建立tcp长连接，在连接上客户端发起心跳，请求响应和接收订阅的通知
这个连接是不是会话呢？不完全是，若连接断了，客户端能在sessionTimeout连上其他Server，那么原会话仍然有效，这里不同连接在同一会话上，那么会话就需要一个全局唯一的sessionID
常用场景：客户端订阅(监听)某个目录，目录改变，Server通知客户端

现在放到集群中考虑：
集群各Server的数据（目录）应该一致，如果每个Server都可写（其他服务器不知道和谁同步状态，若采用写完广播的模式那么各台Server都在广播，数据各种覆盖），显然只有一台Server可写（Leader），其他服务器接收到写请求装发到Leader，写请求需要全局编号（Leader收到多服务器的写请求就知道执行的先后顺序）
其他服务器分Observer和Follower，Follower能选举Leader，并参与“过半写成功”（多数Server写成功，认为数据写成功）

适用于多读少写
顺序一致性（同一客户端的事务请求严格按顺序应用到 ZooKeeper 中去）
原子性（事务请求的处理结果在各台服务器的应用情况都一致）
单一系统映像（无论连哪个服务器，看到数据都是一致的）
可靠性（更改请求被应用，，更改的结果就会被持久化）

（zk）集群间通过 Zab （专用）协议（Zookeeper Atomic Broadcast）来保持数据的一致性，而不是完全采用Paxos（通用）
Zab：崩溃恢复，原子广播
崩溃恢复：刚开始无Leader，或者Leader挂了，选新Leader，过半follower与Leader完成数据同步后（所有的机器follower和observer都会去和Leader同步，但只要follower挂的不多，就有资格进入下个模式），退出恢复模式，进入消息广播模式
广播：这时候Leader上发生改变广播出去就好，但有新机器加入，还是得先和Leader同步

集群为什么奇数？多数（超过一半），3和4都只允许一台挂掉，不如选3（少点），zk的半数是不考虑Observer，只要半数以上节点存活，ZooKeeper 就能正常服务

zk的过半机制？zk需要过半，否则可能脑裂问题(分区耐受性)，但只要过半即可，其它机器宕机，网络分区，机器/网络慢都无所谓
宕机，网络分区属于不可用，恢复后如新机器先和Leader同步
稍微有点慢的机器：慢点没关系，跟着大部队来即可，具体如下
1 选举时已经选出来了，你还有很多票没收到无法统票成功，不着急慢慢来，或者收到确定的选举结果快速加入
2 大部分都同步完成进入广播状态后，你还在同步，不着急慢慢来
3 收到大部分对propose的ack进入commit后，你还没收到propose或收到propose还没发ack或ack还没送达Leader，没关系你的ack不重要，反正Leader会顺序给你propose和commit，你跟着完成数据写入即可

tickTime（心跳间隔，作为时间的基础单位），initLimit（崩溃恢复时过半follower需在此时限内完成同步）
syncLimit（通信的超时时间，比如L向F发心跳包，这个时间内得不到响应就超时）