Zookeeper是什么
- Zookeeper是一个开源的分布式协调框架。它是一个为分布式应用提供服务的软件。
Zookeeper有哪些功能
集群管理
- 监控节点的存活状态、运行请求等
主节点的选举
- 主节点挂掉之后,可以从备用的节点开始新一轮的选主。
分布式锁
:::info
- Zookeeper提供了两种分布式锁机制。
- 独占锁:一次只能有一个线程使用资源。
- 共享锁:共享锁是读锁共享,读写互斥。即:可以有多个线程同时读取同一个资源,如果要使用写锁,也只能有一个线程使用。
:::
命名服务
:::tips
- 在分布式系统中,可以使用命名服务,客户端应用能够指定名字来获取资源或服务地址、提供者等信息。
:::
CAP原则
C:Consistency(一致性)
:::warning
- 系统在执行某个操作后,仍然处于一致的状态。即在同一时刻中,要保持同样的值。
:::
A:Availability(可用性)
:::warning
- 只要用户发起请求,系统就必须及时响应。响应越快,可用性越好。
- 并且每个请求不管成功或者失败都有响应。
:::
P:Partition Tolerance(分区容错性)
:::warning
- 系统中任意信息的丢失或失败不会影响系统的继续运作。
:::
CPA原则
:::info
- CPA原则,是分布式系统参考的三个重要指标。具体是指Consistency 一致性、Availability 可用性、Partition Tolerance 分区容错性。
- CPA原则指出,在一个分布式系统中,不可能同时满足三者。而分区容错性一般是必须具备的重要指标,这也是分布式系统的初衷。因此,实际的业务架构设计中,往往都是对C(一致性)和A(可用性)的权衡和取舍。
:::
Zookeeper是PC架构
Eureka是AP架构
数据的一致性
:::tips
- 在分布式系统中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。
:::
强一致性
:::tips
- 要求无论更新操作是在哪一台服务器执行,之后所有的读操作都能够获取到最新的数据。
:::
弱一致性
:::tips
- 读取到的数据可能不是最新的数据。
:::
最终一致性
:::tips
- 客户端:有可能客户端当前获取的不是最新数据,但是最终还是能访问到最新的。
- 服务端:数据存储并复制到整个分布式系统中,只要超过一半以上的节点,就认为数据操作成功。
:::
Paxos算法
- Paxos算法:是一种基于消息传递且具有高度容错性的一致性算法。
:::success
Paxos算法解决的问题:
- 就是如何快速、正确的在一个分布式系统中对某个数据值达成一致,并且保证不论发生任何异常,都不会破坏整个系统的一致性。
:::
无主集群模型
人人平等,人人都有发送指令和投票的权力。
- 缺陷:
- 导致活锁问题。
- 事务编号混乱,每个节点都有可能有自己的提议。
有主集群模型
- 只能有一个主发送指令,发送提议。
- 缺陷:
- 单点故障。
- 如果存在多个主就会脑裂。
单点故障,从新选举
单点故障
- 重新选举,议员会把票投给数字编号(myid)和事务编号(ZXID)都大于自己的议员。
- 选举过程中,先比较ZXID(为了确定谁的数据是最安全的)。如果ZXID相同,再比较myid。
脑裂出现的原因
:::danger
脑裂出现的原因
- 由于网络波动,将集群分成两块,没有主的集群,就会重新选举。过半原则,如果某个议员获得超过半数以上的选票,就可以成为新主。
- 当网络恢复后,发现集群中存在多个主,就出现了脑裂。
:::
活锁问题
:::danger
活锁
-
事物1可以使用资源,但它让其它事物先使用资源。事物2可以使用资源,但它也让其它事物先使用资源,于是两者一直谦让,都无法使用资源。
-
多个线程争用同一个资源,但是没有任何一个线程能拿到这个资源。
- 活锁是死锁的变种。活锁最终的危害,就是会耗尽CPU资源。(在做无意义的调度)
-
死锁:
- 死锁是有一个线程拿到资源,但相互等待互不释放资源,造成死锁。
:::
- 死锁是有一个线程拿到资源,但相互等待互不释放资源,造成死锁。
Raft算法
Raft算法适用于管理日志一致性的协议。
Raft一致性算法分为:
:::info
- Leader选取。
- 日志复制。
- 安全。
:::
Raft协议的角色
Leader
接受客户端请求并向Follower同步请求日志。当日志同步到大多数节点上后,告诉Follower提交日志。
Follower
被动响应请求,从不主动发起请求。接受并持久化Leader同步的日志。
Candidate
候选者,Leader选举时的一种临时角色。只存在Leader的选举阶段,某个节点想要变成Leader,那么就发起投票请求,同时自己会变成Candidate。
ZAB协议
:::info
- 消息广播
- 崩溃恢复
:::
ZAB协议与Paxos算法的联系与区别
:::success
相同点:
- 两者都存在一个类似于Leader进程的角色,由其负责协调多个Follower进程的运行。
- Leader进程都会等待超过半数的Follower做出正确的反馈后,才会将一个提案进行提交。
- ZAB协议中,每个Proposal中都包含一个Epoch值来代表当前Leader的周期,Paxos中名字为Ballot。
不同点:
- ZAB协议用来构建高可用的分布式数据主备系统(Zookeeper),Paxos算法是用来构建分布式一致性状态的系统。
:::
Zookeeper的常用命令
:::success
开启Zookeeper服务:
**zkServer.sh start**
查看Zookeeper服务的状态:
**zkServer.sh starts**
关闭Zookeeper服务:
**zkServer.sh stop**
:::
Zookeeper的存储模型
Zookeeper的存储结构
- Zookeeper是一种树状结构内存模型,类似文件系统。
- 只是在Zookeeper中将这些目录与文件统称为ZNode,ZNode是Zookeeper中数据的最小单元。
- 每个ZNode上都可以保存数据,还可以挂载子节点。(因此构成了一个层次化的命名空间)
- 数据以K-V的方式存在,目录作为数据的key。
- 所有的数据访问都必须以绝对路径的方式开始(即:以
**/**
开始)。- 每个节点存放数据的上限为1M。
Zookeeper的节点分类【两类四种】
1、持久化节点Persistent
:::success
- 默认创建的节点,就是持久化节点。除非手动删除,否则节点一直存在在Zookeeper上。
:::
2、序列化持久节点Sequential
3、临时节点Ephemral
:::success
- 只要创建节点的会话有效,节点就不会失效。
- 可以被所有的客户端所查看。
- 事务编号和临时节点的编号是一致的。
- 一旦会话结束,临时节点也会被自动删除。(一般这个功能用于判断,节点和服务器是否保持连接)
:::
4、序列化临时节点Sequential
Zookeeper是如果保证事务的顺序一致性
:::info
- Zookeeper采用了全局递增的事务id(
**ZXID**
)来标识,所有的Proposal(提议)都在被提出的时候加上ZXID。- ZXID实际上是一个64位的数字,高32位是Epoch(任期),用来标识Leader的周期。如果有新的Leader产生出来,Epoch(任期)会自动增长。
- 低32位按照数字递增,每次客户端发送一个Proposal(提议)的时候,低32位的数字会自动增1。
:::
Zookeeper的选举机制
第一次启动时:
:::warning
过半原则,服务器id(myid)大的会被选举为Leader。
:::
Leader挂掉时:
:::warning
- 首先会根据任期选择。
- 任期相同,再根据ZXID(事务id)大的
- ZXID(事务id)如果相同,再根据服务器id(myid)大的会被选举为Leader。
:::
:::tips
生产环境下,Zookeeper的安装经验:
- 10台服务器:3台Zookeeper
- 20台服务器:5台Zookeeper
- 100台服务器:11台Zookeeper
- 200台服务器:11台Zookeeper
- 服务器的台数多:
- 好处:提高可靠性。
- 坏处:提高通信延时。
:::
- 服务器的台数多:
Zookeeper下的Server工作状态
1、Looking
:::info
- 寻找Leader状态。
- 当服务器处于该状态时,它会认为当前集群中没有Leader,因此需要进入Leader选举状态。
:::
2、Following
:::info
- 跟随者状态。
- 表示当前服务器角色是Follower。
- 处理客户端的非事务请求,转发事务请求给Leader服务器。
- 参与事务请求Proposal的投票。
- 参与Leader选举投票。
:::
3、Leading
:::info
- 领导者状态。
- 表示当前服务器角色是Leader。
- 事务请求的唯一调度和处理者,保证集群事务处理的顺序性。
:::
4、Observing
:::info
- 观察者状态。
- 表示当前服务器角色是Observer。
- Observer的工作原理和Follower的工作原理基本一致,区别在于Observer不参与任何形式的投票。
- 3.0版本以后引入的一个服务器角色。可以处理客户端的非事务请求,转发事务请求给Leader服务器。
- 不会参与任何形式的投票。
:::
Zookeeper怎么保证主从节点的状态同步
:::tips
Zookeeper的核心是原子广播机制,这个机制保证了各个Server之间的同步。实现这个机制的协议叫ZAB协议。
:::
- ZAB协议有两种模式:
- 恢复模式。
- 当服务器启动或在Leader崩溃后,ZAB就进入了恢复模式。当Leader被选举出来,且大多数Server了和Leader的状态同步以后,恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。
- 广播模式。
- 一旦Leader已经和多数的Follower进行了状态同步后,它就可以开始广播消息了,即进入广播状态。这时候当一个Server加入Zookeeper服务中,它会在恢复模式下启动,发现Leader,并和Leader进行状态同步。待到同步结束,它也参与消息广播。Zookeeper服务一直维持在Broadcast状态,直到Leader崩溃了或者Leader失去了大部分的Follower支持。