标签：架构 Zookeeper 节点 概述 投票 Znode Leader 客户端
目录
下一篇：Zookeeper环境搭建、数据模型、命令与操作、节点属性
Zookeeper概述
根据黑马程序员视频整理
一、概述
Zookeeper是一个开源的分布式协调服务框架，主要用来解决分布式集群中应用系统的一致性问题和数据管理问题
为什么需要？
以前使用锁来解决共享资源的问题，解决的是一台主机上三个共享同一资源的进程
但是现在是三个进程在不同主机上，涉及到网络问题
也是用一个锁，但是是分布式锁
但是共享资源间可能有备份，通过网络同步
主机1要写数据，主机3要读数据，那么1在写的时候3肯定不能读，要等到1写完副本同步了3才能读
以上就都是Zookeeper的活
Zookeeper特点
一、本质上是个分布式文件系统，适合放小文件（最好不超过1m，一般是同步配置文件），也可以理解为一个数据库
在上图左侧，Zookeeper中存储的是一个又一个的Znode，Znode是Zookeeper中的节点
Znode是有路径的，例如/data/host1，/data/host2，这个路径也可以理解为Znode的name
Znode也可以携带数据，例如某个Znode路径是/date/host1，其值是一个字符串"192.168.0.1"
1、Zookeeper是一个集群，分布在多台主机上
用户不关心文件放在哪台主机上，Zookeeper提供一个对外统一的访问路径，一个根目录
抽象出来的文件系统：
这些Znode又具有文件的特性，又具有文件夹的特性（既可以存数据，又可以有子节点）
正因为Znode的特性，可以对外提供一个类似于文件系统的视图，可以通过操作文件系统的方式操作Zookeeper
（增删改查）
使用路劲获取Znode
获取Znode携带的数据
修改Znode携带的数据
删除Znode
添加Znode
Zookeeper的架构
Zookeeper集群是一个基于主从架构的高可用集群
读请求一般为非事务性请求，写请求是事务性请求
follower一般只能处理非事务性请求，如果请求一个写则要由follower转发给leader处理
每个服务器承担如下三种角色的一种
leader：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follower以及Observer间的心跳。所有的写操作必须要通过leader完成再由Leader将写操作广播给其他服务器
Follower：一个Zookeeper集群可能同时存在多个Follower，他们会响应Leader的心跳。
Follower可以直接处理并返回客户端的读请求，同时将写请求转发给Leader处理，负责在Leader处理写请求时对请求进行投票
Observer：角色类似于Follower，但无投票权
Zookeeper应用场景
一、数据发布/订阅系统
Zookeeper采用推拉相结合的模式，客户端向服务端注册自己需要关注的节点
一旦节点数据变更，服务端就会向相应的客户端推送Watcher事件通知
客户端接收到此消息后，主动到服务端获取最新的数据
二、命名服务
分布式系统中被命名实体通常可以是集群中的机器，提供服务地址或远程对象，
通过命名服务，客户端可以根据指定名字来获取资源的实体，
分布式环境中，上层应用仅仅需要一个全局唯一的名字。
Zookeeper可以实现一套分布式全局唯一ID的分配机制
还是利用了Zookeeper的文件节点的特点
步骤
1、客户端根据任务类型，在指定类型的任务下通过调用接口创建一个顺序节点，如：job-
2、创建完成后会返回一个完整的节点名，如job-00000001
3、客户端凭借type类型和返回值后，就可以作为全局唯一id了,如：type-job-00000001
三、分布式协调/通知
1、心跳检测：通过临时节点，发送心跳包，判断对应客户机是否存活
可以大大减少系统耦合
2、工作进度汇报
任务被分配到不同机器，实时汇报任务进度（通过写入到临时子节点）
3、系统调度
修改Zookeeper上的某些节点的数据，把数据变更以时间通知的形式发送给订阅客户端
四、分布式锁
1、排他锁（写锁、独占锁）
（1）、获取锁：在需要排他锁时，所有客户端调用接口在/exclusive_lock节点下创建临时节点exclusive_lock/lock
Zookeeper可以保证只有一个客户端能够创建成功，没有成功需要注册/exclusive_节点监听
（2）释放锁，当获取到锁的占用结束会删除他的临时节点，并通知所有监听客户端，可以重新获取锁
2、共享锁（读锁），当一个事务对数据对象加上共享锁只能做读操作，其他事务也只能加共享锁，直到该对象的所有共享锁都被释放
创建：在/shared_lock下面创建一个临时顺序节点
五、分布式队列
有时候需要一个类似单进程队列的组件，用来实现跨进程、跨主机、跨网络的数据共享和数据传递，这就是我们的分布式队列
Zookeeper选举机制
Leader选举是保证分布式数据一致性的关键所在
进行Leader至少需要两台主句，以下以3台为例
一、服务器启动时期的Leader选举
第一台启动时，无法完成Leader选举，第二台启动的时候，两台机器可以互相通信，并试图找Leader，投票则开始
1、每个Server发出一个投票，Server1和Server2都会将自己定为Leader进行投票
投票包含myid（是个权值，越大越占优势）和ZXID（事务ID，值越大数据越新，越占优势），用（myid,ZXID）表示，此时Server1投（1,0）,Server2投（2,0）
后各自发给集群中其他机器
2、接受来自各个服务器的投票，集群中的每个服务器收到投票后，首先判断该投票的有效性，如是否为本轮投票，是否来自LOOKING状态的服务器
3、处理投票。针对每一个投票，服务器都需要将别人投的票和自己投的票进行PK，
规则：
优先检查ZXID，大的优先作为Leader
ZXID相同则比较myid，myid较大的作为Leader
注意：但投票的服务器一定要过半数
这里对于Server1，它投的是（1，0），接收到Server2投的票是（2，0），ZXID都为0，myid Server2的大，于是更新自己的投票为（2，0），变为自己也支持Server2，然后重新投票，对于Server2无需更新，只需再次向集群中所有机器发出上一次的投票信息
4、统计投票
每次投票后，服务器会统计投票信息，判断是否有过半机器收到了相同的投票信息，对于Server1、Server2都统计出了集群中已经有两台机器接受了（2，0）的投票信息，便认为选出了Leader
这时就算是第三台Server3出来了也不会改变投票结果了
5、改变服务器状态，一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变为FOLLOWING，如果是leader就变为LEADING
Zookeeper集群一般设置为奇数台
二、服务器运行时期的Leader选举
当Leader挂掉了，整个集群将暂停对外服务器，进入新一轮Leader选举，过程和启动时选举基本一致
标签：架构,Zookeeper,节点,概述,投票,Znode,Leader,客户端 来源： https://blog.csdn.net/weixin_46919419/article/details/112442388
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。