zookeeper

一、

1.Zookeeper概述
Zookeeper是一个工具，可以实现集群中的分布式协调服务。
所谓的分布式协调服务，就是在集群的节点中进行可靠的消息传递，来协调集群的工作。
Zookeeper之所以能够实现分布式协调服务，靠的就是它能够保证分布式数据一致性。
所谓的分布式数据一致性，指的就是可以在集群中保证数据传递的一致性。
Zookeeper能够提供的分布式协调服务包括：数据发布订阅、负载均衡、命名服务、分布式协调/通知、集群管理、分布式锁、分布式队列等功能

2.Zookeeper的特点
Zookeeper工作在集群中，对集群提供分布式协调服务，它提供的分布式协调服务具有如下的特点：

• 顺序一致性：从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中
• 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。
• 单一视图：无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。
• 可靠性：一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。
• 实时性：zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。

3.实现原理

zookeeper最重要的特性：保证分布式数据一致性

3.1 可能发生的问题

分布式集群服务部署中

1）若某一台机器的数据有变更，需要顺次通知其他机器变更，若此时一台机器故障，是死等恢复还是返回成功？
死等，若一直恢复不了，影响现有程序运行。
2）若返回成功，当客户端接到处理成功的反馈的同时，故障机器恢复了，如何处理？如何同步数据？
3）若多个客户端同时访问集群中的机器，对同一个变量做相互冲突的修改，A发出x=a，B发出x=b，如何处理？按照命令到达的先后顺序？若几乎同时到达该如何处理？若因为网络延时，后发出的命令反而先到达如何处理？

3.2 实现原理

可靠性：
zookeeper为了保证可靠性，不能用一台机器，而应该是一个集群
因为如果是一台机器的话，就会出现单台故障的问题，如果这一台机器出现问题，就会影响工作

顺序一致性：
客户端发送命令时，附带编号，编号递增，zookeeper按照编号顺序执行
即：客户端发出的每一个命令都要有递增的ID保证顺序一致性

若对机器群中不同的机器发送对同一个变量进行变更
即：集群中要有一个说了算的leader

客户端连接zookeeper时，要做增删改的操作，需要找leader，
如果连接的是leader，直接改
如果是follwer，将请求转发给leader
即：
为了保证zookeeper集群数据能够一致，必须有一个拍板说了算的人，这就是leader，其他的是follower。
某一时刻集群里只能有且仅有一个leader。
leader可以执行增删改和查询操作，而follower只能进行查询操作。
所有的更新操作都会被转交给leader来处理，leader批准的任务，再发送给follower去执行来保证和leader的一致性。


何时告知客户端数据变更成功？
第一种，统一leader告知，
特殊情况，若leader挂掉了，其余未挂掉的机器不知道leader处理过得内容

第二种，民主，由leader告知所有机器，如果所有人都同意，告知客户端
leader告知完，有的机器故障了，如何处理，死等，响应一直处理不了

第三种，尽量通知，尽量接收回馈
当达到一定数量后认为成功
边界值一般选择  过半的条件，即认为成功
例如：5台，则有3台回馈，即认为成功

若故障机器恢复，则与leader保持一致，
若leader故障，则从剩余的机器中与leader保持一致的机器中选择，成为新的leader
即：选择版本比较高的为leader，其余的与leader保持一致

机器数  至少存活  至少挂掉
1 1 0  （单台故障）
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2

即：偶数台与奇数台允许挂掉的机器数相同
多一台机器也未能提供更好的可靠性保

过半即集群失效
即：zookeeper集群中机器的数量最好为奇数个
因为偶然个机器会出现浪费的情况

即：
那么什么时候leader可以认为一个客户端的请求可以算是处理成功了呢？
如果只有leader或少数机器来认可这个任务，则leader和这些少量机器如果挂掉，则选出来的新的leader并不知道之前批准过的这个任务，最终会违反数据的可靠性。
所以要求leader在批准一个任务之前应该保证集群里大部分的机器应该是知道这个提案的，这样即使自己挂掉，根据过半同意选出来的leader肯定是知道这个提案的。
而如果leader一定要等到所有follower都同一才执行提案也不好，因为知道有一个机器挂掉，leader就无法工作，也相当于单节点了，无法保证集群可靠性。
所以，只要过半同一leader就可以认为一个提案通过。
所以，
leader在收到客户端提交过来的任务后，会向集群中所有的follower发送提案等待follower的投票，follower们收到这个提议后，会进行投票，同意或者不同意，
leader会回收follower的投票，一旦受到过半的投票表示同意，则leader认为这个提案通过，再发送命令要求所有的follower都进行这个提案中的任务。

由于需要过半的机器同一才能执行任务，所以一旦集群中过半的机器挂掉，整个集群就无法工作了。

从而可以推导出：
zookeeper集群必须保证过半存活才能工作
zookeeper的集群中的机器数量最好应该是奇数个，因为需要过半存活集群才能工作，所以偶数个机器提供的集群可靠性其实和偶数-1个机器提供的集群可靠性是一样的。

leader选举的问题：
最开始集群启动时，会选择最先启动的机器作为leader。
（其他说法：启动该机器后系统可以正常工作，则该机器为leader，5台中的第3台）
当leader挂掉后，会通过过半投票选出具有最高任务编号的称为新的leader。


机器数  至少存活  至少挂掉
1 1 0  （单台故障）
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2

即：偶数台与奇数台允许挂掉的机器数相同
多一台机器也未能提供更好的可靠性保障
故选择奇数台机器，避免机器数的浪费



初始化时，选择最先启动的机器为leader
启动该机器时刚好可以工作了，该机器为leader
5台中第3台
当leader挂掉后，
暂停对外的工作，互相对外广播自己持有数据的最高版本
向持有版本最高的数据投票，
只要收到过半以上的票数的机器就决定自己是leader
会通过过半投票选出具有最高任务

工作时，
版本低的机器暂时停止服务
与leader机器保持同步后，进行数据的同步
后再提供服务


数据模型
共享的树形结构的名字空间
ZNODE节点
ZNODE本身记录数据
ZNODE包含ZNODE
ZNODE在内存中

高可用：死了一部分认可工作