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的从众机制避免了脑裂
如果主节点恢复了,他会再次向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