zookeeper(二),watcher监听机制，集群搭建

zookeeper事件监听机制
watcher特性：
一次性： watcher是一次性的，一旦被触发就会移除，再次使用时需要重新注册
客户端顺序回调： watcher回调是顺序串行化执行的,只有回调后客户端才能看到最新的数据状态。一个watcher回调逻辑不应该太多，以免影响别的watcher执行
轻量级： watchEvent是最小的通信单元，结构上只包含通知状态、事件类型和节点路径，并不会告诉数据节点变化前后的具体内容。
时效性: watcher只有在当前session彻底失效时才会无效，若在session有效期内快速重连成功，则watcher依然存在，仍可接收到通知。

watcher回调机制有两种状态：
1 watcher通知状态: KeeperState
KeeperState是客户端与服务端连接状态发生变化时对应的通知类型。路径为org.apache.zookeeper.Watcher.Event.KeeperState，是一个
枚举类。
SyncConnected 客户端与服务器正常连接时
DisConnected 客户端与服务器断开连接时
Expired 会话session失效时
AuthFailed 身份认证失败时

2 watcher事件类型: EventType
EventType是数据节点发生变化时对应的通知类型。EventType变化时keeperState永远处于SyncConnected通知状态下。
当keeperState发生变化时，EventType永远为None。其路径为org.apache.zookeeper.Watcher.Event.EventType,是一个
枚举类。
None 无
NodeCreated Watcher监听的数据节点被创建时
NodeDeleted Watcher监听的数据节点被删除时
NodeDataChanged Watcher监听的数据节点内容发生变更时(无论内容数据是否变化)
NodeChildrenChanged Watcher监听的数据节点的子节点列表发生变更时

注意：客户端接收到的相关事件通知中只包含状态及类型等信息，不包括节点变化前后的具体内容，变化前的数据需业务自身存储，
变化后的数据需调用get等方法重新获取。

为znode注册监听：每种方法，监听的范围都不一样。
zk.exists("/node-x",watcher) created changed deleted
zk.getData("/node-x",watcher) changed deleted
zk.getChildren(“node-x”,watcher) childrenChanged deleted

一个节点，可以被多个监听器对象监听。类似于发布/订阅机制，不过监听器对象是一次性。
如需反复使用，可以根据自身业务需求，设置。再次注册监听器，监听此节点。

配置中心案例：
1 连接zookeeper服务器
2 读取zookeeper中的配置信息，注册watcher监听器，存入本地变量
3 当zookeeper中的配置信息发生变化时，通过watcher的回调方法捕获数据变化事件
4 重新获取配置信息

生成分布式唯一ID （临时有序节点）
1连接zookeeper服务器
2 指定路径生成临时有序节点
3 取序列号及为分布式环境下的唯一ID

分布式锁：
传统java并发处理限制：
为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，
在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。

分布式锁解决问题：(对同一共享变量/方法操作，必须先获取锁，才能执行操作。只有当前锁被释放（当前线程方法执行完毕），才能被下一个获得锁的线程获取方法执行权限)
但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、
多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。
为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁设计思路：
1 每个客户端往/Locks下创建临时有序节点/Locks/Lock_,创建成功后/Locks下面会有每个客户端对应的节点。
2 客户端取得/Locks下子节点，并进行排序，判断排在最前面的是否为自己，如果自己的锁节点在第一位，代表获取锁成功。
3 如果自己的锁节点不在第一位，则监听自己前一位的锁节点。例如：
自己锁节点Lock_000000002,那么则监听Lock_000000001
4 当前一位锁节点(Lock_000000001)对应的客户端执行完成,释放了锁，将会触发监听客户端(Lock_000000002)的逻辑
5 监听客户端重新执行第2部逻辑，判断自己是否获得了锁。

zookeeper集群搭建：
1 基于zookeeper-3.4.10复制三份zookeeper安装好的服务器文件，目录名称分别为zookeeper2181,zookeeper2182,zookeeper2183

2 修改zookeeper2181服务器对应配置文件
clientPort=2181 #服务器对应端口号
dataDir=/home/zookeeper/zookeeper2181/data
#集群配置信息
#server.A=B:C:D
#A 是一个数字，表示这个是服务器的编号
#B 是这个服务器的Ip地址
#C zookeeper服务器之间的通信端口
#D Leader选举的端口
server.1=192.168.60.130:2287:3387
server.2=192.168.60.130:2288:3388
server.3=192.168.60.130:2289:3389

3 在上一步dataDir指定的目录下，创建myid文件，然后在该文件添加上一步server配置的对应A数字
echo “1” > myid

重复2,3步骤，部署其他zookeeper服务器。

4 分别启动zookeeper服务器集群。搭建完毕

zookeeper角色：
follower 跟随者，从节点
leader 领导者，主节点
observer 观察者角色及其配置
1不参与leader选举 （提供集群性能,免除了投票过程）
2 不参与集群写数据时的ack反馈，但可以获取到集群中的消息。（提供集群性能,免除了投票过程）
配置zoo.cfg
peerType=observer 观察者节点添加
server.3=192.168.60.130:2289:3389:observer 每个节点都要添加

一致性协议： zab协议。
1 数据一致性。
1 leader向follower发送数据。
2 follower接收数据，并向leader返回接收成功信息(ack)
3 leader 接收到follower消息后，commit提交事务。再发送提交事务请求给follower
4 follower接收到commit请求，再commit本zookeeper服务器事务.
2 zookeeper读写机制。（客户端发送给follower跟随者的请求，都会转发到leader领导者进行处理）

zookeeper的leader选举：
zookeeperAPI连接集群