zookeeper难以理解易混淆的几点

zookeeper难以理解易混淆的几点：

 

 

 

 

 

（一）zk自身主备策略

zk的选举值2n+1多数投票通过才选举为主（自身软件，信号量最大为主，和锁的获得算法无关，zk自身的主备是信号量（zk软件自己数据最新的为主），锁是和节点创建有关）：

1，第一次每个节点先投自己，就是专为只有一个节点时设计的（有多个节点的时候，肯定不是半数通过）

2，每个节点想其他节点发起询问，获得所有其他节点的信息，选后选举投票给记票线程

主只是协调，同步，不做事情的

http://cailin.iteye.com/category/346914

http://cailin.iteye.com/blog/2014486/

https://www.douban.com/note/208430424/

 

 

（二）zk对其管辖进程中的线程锁的策略

zk（核心就是分布式锁）Zab协议（不同服务器执行各自同一个类中同一段代码（会造成数据混乱情况需要））

zk两种锁策略算法（即是锁的获得算法，不是选主的算法，节点排序自小占锁（依次类推，类似条件唤醒）)）（时序锁原理）

1，独占锁，信号量最大的占有锁，其他节点抢占锁失败（都创建同名锁）

2，时序锁，每个节点都可以创建锁，排序最小的先获得锁，这样依次执行

占到锁的执行，没占到锁的等待之后执行（和一个系统中线程等待类似完全安这个理解），也就是说分布式下1用数据库的悲观锁，2通用zk的分布式锁，之前的线程锁用不了，但是原理一致

也是控制访问同一段代码

只是实现方式不同类似用悲观锁前置表（节点）（原理根quartz用悲观锁实现原理一致）（获得锁的原理就是每个线程创建一个节点作为标记，创建节点标记小的线程先执行（自定义锁的思想），传统用用关键字就有锁了）

 

 

（三）两阶段提交，都内存预提交后可以就提交

涉及修改操作的都会由多次预提交，最终由leader决定时候提交。

而需要分布式锁的都是修改操作，那么这样的每个线程请求都需要预提交

两阶段提交是不需要代码开发的，自然根据session操作的类型是更新操作的就自动统一由主确定是否能提交（多数节点预提交成功）

数据库相关的双主的同步通过互为设置主的方法，activeMq的双主是分别设立两个主，主之间打通通信通道deplux=true

 

 

另，zk的从众机制避免了脑裂（原因是由于采用sharing store ，共享文件系统，有锁，获取锁的才是主，网络不稳定断开的master，其他从重新选还是获取不到master的锁（master还在不会释放））

 

如果主节点恢复了，他会再次向ZooKeeper注册一个节点，这时候他注册的节点将会是"master-00003"，ZooKeeper会感知节点的变化再次发动选举，

这时候"主节点-B"在选举中会再次获胜继续担任"主节点"，"主节点-A"会担任备用节点

http://www.cnblogs.com/thinkpad/p/5041493.html(这里说明zk避免了脑裂问题)

 (3) Master 恢复

图7.8 ZooKeeper Master选举

如果主节点恢复了，他会再次向ZooKeeper注册一个节点，这时候他注册的节点将会是"master-00003"，ZooKeeper会感知节点的变化再次发动选举，这时候"主节点-B"在选举中会再次获胜继续担任"主节点"，"主节点-A"会担任备用节点。

 

 

http://cailin.iteye.com/blog/2246940