ZooKeeper学习

参考链接:
https://blog.csdn.net/java_66666/article/details/81015302
https://blog.csdn.net/u010775025/article/details/79205992
https://blog.csdn.net/qq_18416057/article/details/54927189
https://blog.csdn.net/oldshaui/article/details/84658145
https://blog.csdn.net/qiushisoftware/article/details/79043379
https://blog.csdn.net/fenglongmiao/article/details/79305010
https://blog.csdn.net/xinguan1267/article/details/38422149

Zookeeper理解:
ZooKeeper是一个集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务。
ZooKeeper是一个高性能，分布式的，开源分布式应用协调服务,以此来协调分布式系统中的各个应用服务。它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
简单来说zookeeper=文件系统+监听通知机制。

1、 文件系统

每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
1）Znode有两种类型：
短暂（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除
持久（persistent）：客户端和服务器端断开连接后，创建的节点不删除

有四种类型的znode：

• PERSISTENT-持久化目录节点
  客户端与zookeeper断开连接后，该节点依旧存在
• PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
  客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
• EPHEMERAL-临时目录节点
  客户端与zookeeper断开连接后，该节点被删除
• EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
  客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

2、 监听通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
假设我们的程序是分布式部署在多台机器上，如果我们要改变程序的配置文件，需要逐台机器去修改，非常麻烦，现在把这些配置全部放到zookeeper上去，保存在 zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 zookeeper 的通知，然后从 zookeeper 获取新的配置信息应用到系统中。

Zookeeper功能:
1、维护配置信息
应用场景：
比方说你有20多个，甚至更多的项目，共同使用很多配置文件。当你要修改配置文件时，你是不是要一个个去复制一遍，这样很耗时间，精力，而且也不利于管理。而且现在项目都是分布式项目，在加上如果项目已经上线，那你如果一个个去改，然后重启服务，那不是麻烦死了。

zookeeper提供的这个配置管理，就是把这公用的配置文件提取出来放到一个地方，对这个地方（目录节点）进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好，项目不需要重启，这样上面一开始讲的问题就解决了.
参考文章：http://www.jianshu.com/p/01388f06e75d

2、命名
用过duboo+zookeeper整合的系统的人知道，因为命名服务，才方便了分布式各个项目之间的联系 。在集群，和分布式环境下，如何做到子项目之间调用的关系不会很复杂，不会到时候出现问题都不知道哪个服务调用的哪个，所以这里就需要一个服务器专门替我们管理这里服务的信息和调节，管理这些服务，让我们可以把集中与项目的业务，zookeeper的命名功能就是这么一个服务器。当集群的时候，相同的一个服务有很多个提供者，这些提供者启动时，提供者服务器的相关信息，包括服务接口，地址，端口等一下连接提供者的信息注册到zookper中，当消费者要消费某服务的时候，从zookeeper中拿改服务的所有提供者信息目录，再根据dubbo的负载均衡机制从地图中选择一个提供者。其实从作用1,2可以看出，zookeeper大家可以看出是一个文件系统（类似与linux文件系统），还是那句话，zookeeper就是分布式中充当大脑。

3、分布式同步
分布式的同步，又叫分布式锁。在分布式上，如果A要调用B的方法C，C方法也要加锁，但这个锁不能像单服务器那样加，因为这个是分布式调用的方法，不一样。就像事务一样，单服务器上的事务和分布式事务不一样。zookeeper提供了一个分布式同步（锁）的方法，使用其提供的，客户可以省了很多事。

zookeeper分布式锁的思路
进程需要访问共享数据时, 就在"/locks"节点下创建一个sequence类型的子节点, 称为thisPath. 当thisPath在所有子节点中最小时, 说明该进程获得了锁. 进程获得锁之后, 就可以访问共享资源了. 访问完成后, 需要将thisPath删除. 锁由新的最小的子节点获得.

有了清晰的思路之后, 还需要补充一些细节. 进程如何知道thisPath是所有子节点中最小的呢? 可以在创建的时候, 通过getChildren方法获取子节点列表, 然后在列表中找到排名比thisPath前1位的节点, 称为waitPath, 然后在waitPath上注册监听, 当waitPath被删除后, 进程获得通知, 此时说明该进程获得了锁.

zookeeper分布式锁的原理 https://my.oschina.net/91jason/blog/500503

4、提供组服务
其实这个组服务也就是集群管理了，就像dubbo+zookeeer。服务器上的服务注册，或者获取服务，都是在zookeeper上操作的，所以所谓的提供组服务也就包括创建组、加入组成员、列出组成员和删除组成员。对于这些服务，主要通过zookeeper心跳机制，它会去检测与其连接的一些服务器的数量，以及信息。什么时候连上zookeeper，或什么时候断开都有其心跳机制完成。

Zookeeper集群:
Zookeeper集群中节点个数一般为奇数个（>=3），若集群中Master挂掉，剩余节点个数在半数以上时，就可以推举新的主节点，继续对外提供服务
客户端发起事务请求，事务请求的结果在整个Zookeeper集群中所有机器上的应用情况是一致的。
在Zookeeper集群中的任何一台机器，其看到的服务器的数据模型是一致的。
Zookeeper集群中的节点，根据其身份特性分为leader、follower、observer。
leader负责客户端writer类型的请求；
follower负责客户端reader类型的请求，并参与leader选举；
observer是特殊的follower，可以接收客户端reader请求，但是不会参与选举，可以用来扩容系统支撑能力，提高读取速度。
Zookeeper是可以集群复制的，集群间通过ZAB(Zookeeper Atomic Broadcast 原子消息广播协议)协议来保持数据的一致性。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识eader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

Zookeeper集群选主流程: https://blog.csdn.net/liuyuehu/article/details/52136945
选举算法(fast paxos 系统默认) 和(basic paxos)
basic paxos算法:
1 .选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2 .选举线程首先向所有Server发起一次询问(包括自己)；
3 .选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息( id,zxid)，并将这些信息存储到当次选举的投票记录表中；
4. 收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数， 设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。

zxid
　　• znode节点的状态信息中包含czxid, 那么什么是zxid呢?
　　• ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.

fast paxos流程:
在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。

这俩选举方法没怎么懂 fast paxos选举主要是解决多个server同时选举自己当leader。

ZooKeeper Client API
ZooKeeper Client Library提供了丰富直观的API供用户程序使用，下面是一些常用的API：

• create(path, data, flags): 创建一个ZNode,
  path是其路径，data是要存储在该ZNode上的数据，flags常用的有: PERSISTEN,
  PERSISTENT_SEQUENTAIL, EPHEMERAL, EPHEMERAL_SEQUENTAIL
• delete(path, version): 删除一个ZNode，可以通过version删除指定的版本,
  如果version是-1的话，表示删除所有的版本
• exists(path, watch):
  判断指定ZNode是否存在，并设置是否Watch这个ZNode。这里如果要设置Watcher的话，Watcher是在创建ZooKeeper实例时指定的，如果要设置特定的Watcher的话，可以调用另一个重载版本的exists(path,watcher)。以下几个带watch参数的API也都类似
• getData(path, watch): 读取指定ZNode上的数据，并设置是否watch这个ZNode
• setData(path, watch): 更新指定ZNode的数据，并设置是否Watch这个ZNode
• getChildren(path, watch): 获取指定ZNode的所有子ZNode的名字，并设置是否Watch这个ZNode
• sync(path): 把所有在sync之前的更新操作都进行同步，达到每个请求都在半数以上的ZooKeeper Server上生效。path参数目前没有用
• setAcl(path, acl): 设置指定ZNode的Acl信息 getAcl(path): 获取指定ZNode的Acl信息