ZooKeeper
分布式管理系统存在的问题
多个计算机联系成分布式管理系统，会得到算力可以无限扩张等好处。但是缺点也是显而易见的。
想象成一个大型的开发团队，那么存在的问题就如任务如何分配？谁当leader？leader离职后谁上任？员工离职后谁上任等问题
解决方法：利用ZooKeeper进行信息在项目组的同步
所以ZooKeeper的功能：分布式系统的分布式协同服务
ZooKeeper
是什么
ZooKeepe是基于共享存储svn进行节点之间信息的共享。主节点为Master，ZooKeeper是 svn，每一个从节点就是slave组员。svn存储了任务的分配、完成情况等共享信息。每个分布式应用的节点就是组员，订阅这些共享信息。
主节点向ZooKeeper更新任务数据
ZooKeeper向相关订阅的从节点发出通知
从节点从ZooKeeper取得自己最新的任务分配
从节点将完成的数据存储到zookeeper
zookeeper通知主节点完成
是什么
利用znode进行存储信息
根节点/包含4个子节点
即使节点上没有存储数据，也有着重要的含义。比如在主从模式中，当/master节点没有数据时，代表分布式应用的主节点还没有选举出来。
四个节点分别是：
/master，存储了当前主节点的信息
/workers，下面的每个子znode代表一个从节点，子znode上存储的数据，如“foo.com:2181”，代表从节点的信息。
/tasks，下面的每个子znode代表一个任务，子znode上存储的信息如“run cmd”，代表该内务内容
/assign，下面每个子znode代表一个从节点的任务集合。如/assign/worker-1，代表worker-1这个从节点的任务集合。/assign/worker-1下的每个子znode代表分配给worker-1的一个任务。
持久节点（persistent）和临时节点（ephemeral）
持久节点只能通过delete删除。临时节点在创建该节点的客户端崩溃或关闭时，自动被删除。
/master应该使用临时节点，这样当主节点失效或者退出时，该znode被删除，其他节点知道主节点崩溃了，开始进行选举的逻辑。
/works/worker-1也应该是临时节点，在此从节点失效的时候，该临时节点自动删除。
怎么做
通知
客户端向zookeeper请求，在特定的znode结点master设置观察点（watch）即订阅。
当该znode发生变化时，zookeeper通知客户端，客户端收到通知后进行业务处理。
观察点触发后立即失效。所以一旦观察点触发，需要再次设置新的观察点
我们使用Zookeeper不能期望能够监控到节点每次的变化。思考如下场景：
1、客户端C1设置观察点在/tasks
2、观察点触发，C1处理自己的逻辑
3、C1设置新的观察点前，C2更新了/tasks
4、C1处理完逻辑，再次设置了观察点。
此时C1不会得到第三步的通知，因此错过了C2更新/tasks这次操作。要想不错过这次更新，C1需要在设置监视点前读取/tasks的数据，进行对比，发现更新。
再如下面的场景：
1、客户端C1设置观察点在/tasks
2、/tasks上发生了连续两次更新
3、C1在得到第一次更新的通知后就读取了/tasks的数据
4、此时第二次更新也已经发生，C1用第一次的通知，读取到两次更新后的数据
此时C1虽然错过了第二次通知，但是C1最终还是读取到了最新的数据。
因此Zookeeper只能保证最终的一致性，而无法保证强一致性。
仲裁模式
在集群中有很多个服务器，当上传数据时候，如果所有服务器都更新数据，那么会很慢。
引入法定人数，即只需要法定人数个服务器更新数据，那么就认为数据已经更新。注意，法定人数必须大于一半，即满足多数原则
为什么要遵循多数原则?这里应该是有一个前提，挂掉服务器超过集群服务器数量的一半时，集群认为自己崩溃
5台服务器，法定人数为2，如果挂了2台，剩下三台超过了服务器集群数量的一半，集群认为自己正常运行，但是已经缺失数据
5台服务器，法定人数为3，如果挂了2台，还剩下一台服务器拥有数据，此时集群仍然保留了数据
所以我们尽量选用奇数个服务器，允许挂掉的比例问题
会话
客户端向服务器请求时必须要建立绘画
创建会话时，需要设置会话超时这个重要的参数t。如果经过时间t后服务接受不到这个会话的任何消息，服务就会声明会话过期。客户端在t/3时间未收到任何消息，客户端向服务器发送心跳消息，2t/3时间后，客户端开始寻找其他服务器这里我理解为客户端认为服务器挂掉了。此时他有t/3的时间去寻找，找不到的话，会话失效。
事务标识符
服务器更新时会改写事物标识符，同样客户端连接服务时也携带事物标识符，只有ke服务器的事物标识符大于客户端携带的标识符时，才可连接，以免链接到落后的服务器
引用：https://blog.csdn.net/liyiming2017/article/details/83035157