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的从众机制避免了脑裂

 

如果主节点恢复了,他会再次向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

 

展开阅读全文

没有更多推荐了,返回首页