ZooKeeper全局锁WriteLock选举的BUG
最近项目中采用ZK去选择分布式集群的Master/Slave，生产环境运行一段时间中，经常出现同时存在多个Master的问题，然后去阅读了一下ZK扩展包的源码，发现两个BUG：BUG：多机器同时获取WriteLock全局锁时有可能会有多个机器成为Leader。
原因分析：WriteLock创建临时自增节点是采用x-session_id-sequece_no的方式，在选举Leader时，通过TreeSet对节点进行排序，最小的节点就会被选为Leader，其它的会被选为Follower。由于ZNodeName的compareTo方法的实现问题，WriteLock获取的锁时并不是按sequence_no最小的来选择，而是先根据session_id的字符串进行比较，再比较sequence_no，如果WriteLock后创建的节点的session_id比前面的小（可能性比较大），这种比较方式就有可能导致产生多个Leader。如：
机器1创建了：x-231622919316419832-0000000183
机器2创建了：x-231622919316419833-0000000184
机器3创建了：x-87556941509467773-0000000185
机器4创建了：x-159565318739768636-0000000186
由于机器1最先启动，只有一个节点生成，所以理所当然成为Leader，但由于ZNodeName的compareTo方法的问题，机器4启动后发现session_id值比当前Leader的值要小，所以机器4也被认为是Leader，这样就同时存在了两个Leader。
另外，不仅在机器启动和重启的时候发生，ZK会话超时重连，而会出现此情况。
如何改造：
去除ZNodeName的compareTo方法对session_id的比较，仅保留对sequece_no的比较。
页:
[1]