zookeeper笔记

1. zookeeper数据模型结构可看做一棵树。每个节点（文件目录）称做znode，每个znode默认可存1MB数据，可以通过其路径唯一标识。无法存储海量数据，只适合存储一些配置数据。
2. zookeeper可统一命名服务。在分布式环境中，需要对应用、服务统一命名（IP不好记，而域名容易记住）。可统一配置管理。一般要求一个集群中，所有节点的配置信息是一致的。假如对配置文件做了修改，希望快速同步到所有节点上。可统一集群管理。将某个节点信息写入到一个znode中，这样可通过监听znode，知道这个节点的运行状态。可软负载均衡。根据不同节点的访问数，引导客户端到最优节点上访问。
3. zookeeper配置文件 zoo.cfg 参数解读。
   tickTime = 2000 通信心跳时间，zookeeper服务器和客户端心跳时间，单位毫秒。
   initLimit = 10 LF（leader、follower）初始通信时限。两者初始连接时能容忍的最多心跳数。即如果初始化时，20s都没有建立心跳连接，则认为通信失败。
   syncLimit = 5 LF同步通信时限。上面的参数是初始化，这个参数是已经建立连接后，Leader和Follower之间通信时间如果超过10s，则leader认为follower死掉，从服务器删掉follower。
   dataDir：保存zk数据的目录。默认tmp目录，但tmp中数据会定期删除，所以需要自己手动修改下。
   clientPort = 2181 客户端连接端口。
4. zookeeper选举机制
   第一次启动时选举，共5台服务器
   服务器s1启动，发起一次选举。s1投自己一票，不够半数以上，选举无法完成，s1保持 LOOKING状态。
   服务器s2启动，再发起选举，s1和s2分别投自己一票并交换选票信息，此时s1发现s2的myId比自己目前投票推举leader的myId更大，所以更改选票为s2。此时s1是0票，s2是2票，没有超过半数，选举无法完成。s1 s2保持LOOKING
   服务器s3启动，再发起选举，由上所述，三台服务器选票依次为0票 0票 3票。超过半数，选举完成，s3当选leader。s3更改状态 LEADING，s1 s2 更改状态 FOLLOWING。
   服务器s4启动，再发起选举，此时，前三台服务器已经不是LOOKING状态，不会改变选票信息。交换选票结果：s3是3票，s4是1票，少数服从多数，s4更改状态 FOLLOWING。

正常启动后，如果s5无法和leader保持连接。它自己会进入选举流程。此时有两种可能。
一是集群中leader仍然存在，只是因为某种原因无法保持连接。此时，s5会被其他机器告知当前集群的leader信息，s5会尝试与leader建立连接，之后进行状态同步即可。

二是集群中确实不存在leader。重新选举前先理解3个id的概念。他们会影响下一次选举的结果。
SID 服务器id，唯一标识一台机器，不能重复和myId一致
ZXID 事务id 标识一次服务器状态的变更。某一时刻，集群中每台机器的ZXID不一定一致。类比git版本控制的版本号。
Epoch：每个leader任期的代号。没有leader时同一轮投票过程中该值是相同的，每投完一次票这个数据就会增加。

继续重新选举
假设zookeeper由5台服务器组成，sid分别是1到5，zxid分别是8 8 8 7 7，s3是leader。突然s3和s5出故障了，新一轮选举开始。
每台机器都有（Epoch，ZXID，SID）三个值组成的triple。s1是 （1，8，1），s2是 （1，8，2），s3是 （1，7，4）
选举leader规则：epoch大的直接胜出; epoch相同，事务id大的胜出; 事务id相同，服务器id大的胜出。
所以，最终s2被选为新的leader。

5. zookeeper节点类型
   持久 客户端和服务端断开连接后，创建的节点不删除
   短暂 断连后，创建的节点删除
   同时，创建节点时还可以选择是否带序号，也就是znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。序号有什么作用呢？其实，在分布式系统中，顺序号可被用于为所有的事件全局排序，这样客户端可以通过序号推断事件的顺序。
6. 监听器原理
   客户端注册服务端监听。当对应服务端节点发生变化时，服务端会通知客户端。然后客户端再做下一步行动。常见的监听有节点数据的变化、子节点增减的变化。
7. 客户端向服务端写数据原理
   有两个可能性：写入请求直接发给leader 和 写入请求发送给follower
   假设有1个客户端c1,3个服务端s1、s2、s3。s1是leader。
   发给leader流程如下：c1给s1 leader发写入请求，s1给s2发更新请求，s2给s1发ack确认写入，因为此时已经有半数以上的节点写入成功。所以s1给c1发ack，确认写入。然后s1再给s3发更新请求，s3给s1发ack确认。

发给follower流程如下：c1给s2发写入请求，s2没有写入权限，s2会把写入请求转给s1，s1写入后，再给s2发写入请求，s2写入成功后，给s1发ack确认。此时已经写入的机器超过半数，s1再给s2发ack确认半数机器已经更新成功，可以给c1返回。s2再给c1发ack。s1继续给s3发写入请求，直至所有机器都写入成功。从这里我们也能看出，zookeeper一个重要的设计理念：少数服从多数。

8. 用zookeeper可以实现分布式锁，不过比较复杂。有现成的 curator 框架实现分布式锁。
9. 如何解决分布式系统的一致性问题。
   Paxos算法：基于消息传递且具有高度容错性的一致性算法。
   在一个paxos算法中，所有节点都划分为Proposer（提议者）、acceptor（接受者）和learner（学习者）。每个节点都可以身兼数职。一个形象的理解是，提议者是议长，接受者是有投票权的议员，学习者是弃权的议员。

一个完整流程包含3个阶段：
Prepare准备阶段：Proposer向多个acceptor发出propose请求Promise（承诺）、acceptor针对收到的请求进行Promise（承诺）。议长对议员说，兄弟们投我一票，议员对议长说，没问题，兄弟们支持你。
Accept接受阶段：Proposer收到多数Acceptor的承诺后，向acceptor发出Propose请求。acceptor针对收到的请求进行accept处理。议长提出了具体的议案，议员们赞成通过。
Learn学习阶段：Proposer将形成的决议发送给所有learners。只要议案通过，弃权的议员同样也要学习执行。
但是这种算法有个缺点：多个proposers相互争夺acceptor，造成迟迟无法达成一致的情况。于是，一种改进paxos算法的思路是：从系统中选出一个节点作为leader，只有leader能发起提案。这样能防止上述的活锁。这就是zab协议。
zookeeper底层用的就是zab协议。

10. zab协议流程
    客户端发起写操作，leader将请求转化为proposal提案，同时为每个proposal分配一个全局的zxid。leader为每个follower分配一个单独的队列，将需要广播的proposal依次放到队列中，根据FIFO策略进行消息发送。follower接收到proposal后，先将其以日志形式写入磁盘中，写入后向leader发送ack确认。leader收到超过半数的ack后，认为消息发送成功，于是再向所有follower广播commit消息，同时自身也完成事务提交，follower接收到commit消息后，会将上一条事务提交。
    上面的流程简单总结下来有两步：广播事务阶段和广播提交操作。

11. zab协议的崩溃恢复
    其实就是leader在不同阶段崩溃后，从剩下的follower中选新leader的算法。上面已经讲过了，不赘述。

12. cap理论
    C consistency 一致性；A available 可用性；P partition Tolerance 分区容错性。所谓分区容错性，是说分布式系统在任何网络分区故障的时候，仍然能保证对外提供满足一致性和可用性的服务。
    这三个基本需求，最多只能同时满足其中两项，P是必须的。因此往往就选择CP or AP。
    zookeeper满足的是CP。为什么这么说呢。因为zookeeper在极端情况下，不保证每次请求都能拿到结果，满足可用性。它会丢弃一些请求，保证一致性。另外，在选举leader时，zookeeper集群是不可用的。有leader后才可用。