zokeeper选举机制及流程c

zookeeper选举机制

第一次启动选举机制

因为各个节点都没有数据，所以依据的选举策略是，serverID进行比较，启动的节点首先给自己投票，然后与其他启动的节点进行通讯，serverid大的获取投票并且超半数才可当选。

非第一次启动选举

1.Epoch大的直接胜出

2.epoch相同，事务id大的胜出

3.事务id相同，seriveid大的胜出

 

https://www.cnblogs.com/zyd-994264926326/p/15162642.html

对于zookeeper的理解可以从分布式系统中三种典型的场景来说第一种是集群管理，在多个节点组成的集群红，为了去保证集群的高可用特性，每个节点都会去冗余一份数据副本，这种情况下需要保证客户端访问集群种，任意一个节点都是最新的数据第二种分布式锁，如何保证跨进程的共享资源的并发安全性，对于分布式系统来说，也是一个比较大的一个挑战，为了达到这个目的必须要使用跨进程的锁，也就是分布式锁来实现第三种Master选举，在多个节点组成的集群中，为了降低集群数据同步的一个复杂度，一般会存在Master和Slave两种角色的节点，master负责去做事务和非事务的请求 处理，Salve去做专门负责非事务的请求处理，但是在分布式种如何去确定某个节点是Master还是slave也是一个挑战。基于这三种场景所以产生了zookeeper这样一个中间件，他是一个分布式开源的协调组件，简单来说就是类似一个裁判员的一个角色，专门负责协调和解决分布式系统中的各类问题，比如针对上述的问题都可以用zookeeper来解决第一个集群管理，zookeeper提供了CP模型，来保证集群中的每一个节点的数据一致性，当然zk本身并不是一个强一致性的模型，而是一个顺序一致性模型，如果我们需要去保证CP特性的话，需要调用sync方法去进行同步第二个分布式锁，zookeeper提供了多种不同的节点类型，比如持久化节点，临时节点，有序节点，和容器节点等等。其中对于分布式锁场景来所，可以利用有序节点这样一个特性来实现，除此之外，还可以同一节点的唯一特性来实现分布式锁第三个master选举，zk可以利用持久化节点来存储和管理其他集群节点的一些信息，从而去进行master选举的机制，或者还可以利用集群中的一些有序系欸但那的特性来实现Master选举，目前主流的kafka集群都是通过zookeeper来实现的总来来说zk是分布式数据一致性协调解决方案，它主要致力于分布式应用中的一些高性能，高可用的并且就严格访问顺序控制的一些能力模型，实现分布式的协调服务，它底层的数据一致性算法是基于Paxos算法演进而来的zab协议