诸位端午安康,我们今天趁假期浅析一下Zookeeper相关知识,话不多说,开始食用。
Zookeeper 是一个分布式的协调服务,可以用来管理共享数据、配置信息、命名服务(如 DNS)和分布式锁等。
Zookeeper 的特点是具有高可用、一致性和可靠性,因此也被广泛应用于分布式系统中。
Zookeeper的主要组成包括:
图片来源自网络,如侵则删
总的来说,服务注册流程是一个基于Zookeeper的分布式的服务注册与发现的过程。服务提供者将自己的服务信息写入Zookeeper节点中,服务消费者通过监听节点的变化来获取服务列表,从而实现了服务的注册与发现。
总的来说,Zookeeper的运行流程是一个分布式的协作过程,它通过选举Leader、同步数据、监听节点变化等机制,实现了分布式应用程序的协调与管理。
Zookeeper的正常运行是强依赖于Leader的存在的,所以想要正常运行必须要先选举出Leader角色。
选举的过程是基于Zookeeper节点名称的字典序排序,而不是节点的性能或处理能力。
选举基于Zookeeper的Zab协议的广播版本,该协议保证了全局数据的一致性,主要是通过扩展Paxos协议来实现的。当一个Leader不可用时,剩余的节点立即开始选举新的Leader。
这里要引入一个新的名词Candidate(候选者)节点,关于参与选举Zookeeper中的Leader(领导者)角色网上有不同的说法:
二者的区别我们后文会做说明,此处只需要记住这两种说法都不错。
节点名称在Zookeeper中是唯一的,如果多个节点拥有相同的名称,则会发生错误,因此节点名称的选择是非常重要的。可以通过有意义的命名规则来确保节点名称的唯一性,以避免命名相同或类似的节点。
不过,当在同一节点上部署多个Zookeeper服务器实例时,每个实例必须有一个独特标识符,例如端口号或服务器编号,以确保它们的名称不同,从而避免冲突。
选举流程如下:
这时,所有的非Leader节点将参与新的选举。
Zookeeper中,观察者(watcher)是一种机制,用于实现数据变更的通知和事件驱动。
观察者本质上只是客户端,所以它不会在集群中发挥管理角色,也不会影响到Leader的选举过程。
当Zookeeper中某个节点的数据发生变化时,Zookeeper会触发该节点上的所有客户端注册的watchers,并将通知发送给这些客户端,这样客户端就能及时感知数据变化,从而进行相应的处理。
观察者的作用主要有以下几个方面:
总之,观察者(watcher)是Zookeeper中重要的机制之一,通过该机制,可以实现数据变更的通知和事件驱动,提高系统的可用性和性能。
Candidate(候选者)节点是准备参与Leader选举的节点,它们会发起选举请求,并等待集群中的其他节点的确认,其本质上还是Follower(跟随者)节点,只不过两者的节点状态不一样。
Follower节点是Zookeeper集群中的一种常规节点状态,它的主要作用是接收Leader节点的数据更新,并将这些更新通知给其他节点。Follower节点可以参与Leader选举,但它不能直接成为Leader节点。在Zookeeper集群中,大多数节点都是Follower节点。
Candidate节点是Zookeeper集群中的一种特殊节点状态,它是指正在参与Leader选举的节点。在Zookeeper集群中,当一个节点想要成为Leader时,它会将自己的状态从Follower节点切换到Candidate节点,然后开始参与Leader选举。Candidate节点会向其他节点发送选举请求,收到半数以上节点的投票后,它就可以成为Leader节点。
总之,Follower节点是Zookeeper集群中的一种常规节点状态,而Candidate节点是一种特殊的状态,它是指正在参与Leader选举的节点。
如果ZooKeeper的Leader节点挂掉并且重新选举新的Leader节点时,尚未完成的写操作可能会丢失;这是因为,当Leader节点挂掉后,ZooKeeper会立即停止处理写操作,直到重新选举出新的Leader节点;在这个过程中,如果其他Follower节点已经复制了未同步的写操作,而这些Follower在重新选举新的leader之前也因某些原因宕机了,那么这些未同步的写操作可能会因为Follower节点宕机而丢失。
为了避免数据丢失,一些应用程序也会使用ZooKeeper的事务支持来保证多个写操作的原子性。这可以通过在ZooKeeper的JavaScript客户端API中使用事务的方式来实现。
Zookeeper 的使用需要格外注意网络分区、容错处理等问题,但是只要合理地设计代码逻辑和容错机制,依然可以达到高可用、一致性和可靠性的目标。