zookeeper 的一致性协议 zookeeper一致性原理

转载

mob64ca14092155 2024-04-21 20:10:23

文章标签 zookeeper 的一致性协议 zookeeper 数据子节点数据一致性 文章分类 运维

@T- CZookeeper集群一致性原理(强一致性)

强一致性,弱一致性,最终一致性概念

强一致性概念
步骤1修改了userName为beid- uxing,步骤2读到的结果也一定是为beid- uxing
实现方式

mysql主从复制非常迅速,同步
锁机制,必须等待mysql1数据同步到mysql2的时候,这个时候才可以读取
注意:在分布式领域中是很难保证强一致性
弱一致性概念

允许数据库之间同步存在短暂延迟,步骤2读取userName内容为future而不必为beid- uxing;这种我们称作为弱一致性

最终一致性

就是步骤1修改了userName为beid- uxing,允许步骤2读取的时候还是原来的数据future;但是最终数据一定同步为beid- uxing
Zookeeper集群

Zookeeper各个节点数据是如何实现同步的?

Zk集群是由多个Server节点组成的一个集群,只有一个Leader节点;其他节点类型都是F- ll- wer类型
1.每个F- ll- wer节点保存了Leader节点的副本数据
2.全局保证数据一致性问题
3.分布式读写分离; 写的请求统一交给Leader实现,F- ll- wer或者- bserver节点主要实现读的操作
注意:如果我们连接的节点类型是- bserver或者F- ll- wer情况下做写的操作的时候直接转发到Leader实现写
进行读操作的时候,访问领导者,领导者也会转发给跟随者和观察者
为什么zk写的请求都是Leader写完成之后同步给每个F- ll- wer节点
Zookeeper ZAB协议源于消息广播实现原理

Zookeeper At- mic Br- adcast 原子消息广播协议

ZAB协议和Pax- s算法的区别

ZAB底层是基于2PC协议(tw- -phase c- mmit两阶段提交)
解决分布式数据一致性
ZAB协议并不是Pax- s算法的一个典型实现，在讲解ZAB和Pax- s之间的区别之前，我们首先来看下两者的联系。两者都存在一个类似于Leader进程的角色，由其负责协调多个F- ll- w进程的运行。Leader进程都会等待超过半数的F- ll- wer做出正确的反馈后，才会将一个提案进行提交。在ZAB协议中，每个Pr- p- sal中都包含了一个ep- ch值，用来代表当前Leader周期，在Pax- s算法中，同样存在这样一个标识，只是名字变成了Ball- t。在Pax- s算法中，一个新选举产生的主进程会进行两个阶段的工作。第一阶段被称为读阶段，在这个阶段中，这个新的主进程会通过和所有其他进程进行通信的方式来收集上一个主进程的提案，并将他们提交。第二阶段被称为写阶段，在这个阶段，当前主进程开始提出他自己的提案。在Pax- s算法设计的基础上，ZAB协议额外添加了一个同步阶段。在同步阶段之前，ZAB协议也存在一个和Pax- s算法中的读阶段非常类似的过程，称为发现（Disc- very）阶段。在同步阶段中，新的Leader会确保存在过半的F- ll- wer已经提交了之前Leader周期中的所有事务Pr- p- sal。这一同步阶段的引入，能够有效地保证Leader在新的周期中提出事务Pr- p- sal之前，所有的进程都已经完成了对之前所有事务Pr- p- sal的提交。一旦完成同步阶段后，那么ZAB就会执行和Pax- s算法类似的写阶段。总的来讲，ZAB协议和Pax- s算法的本质区别在于，两者的设计目标不太一样。ZAB协议主要用于构建一个高可用的分布式数据主备系统，例如ZooKeeper，而Pax- s算法则是用于构建一个分布式的一致性状态机系统。

Zookeeper和Eureka实现注册原理区别
ZAB原子广播协议核心是保证各个节点数据同步问题
ZAB协议中两种模式

崩溃恢复模式

选举新的Leader

广播消息模式

解决每个节点数据同步问题
当我们响zk种发送一个事务请求的时候,这个时候我们的Leader节点就会创建一个全局的zxid事务id
底层采用2PC两阶段提交协议
第一阶段同步的时候带上zxid,告诉每个F- ll- wer是否可以允许同步数据

每个F- ll- wer节点收到请求后,确认没问题,我们每个F- ll- wer节点都可以接收同步数据,响应给Leader节点(确认)

确认完成之后,Leader节点就会收到各自的F- ll- wer节点,只要超过半数的F- ll- wer节点确认允许同步的情况下,Leader节点就会进行C- mmit,把这些数据发送给F- ll- wer节点
原理:

Leader处理写事务请求(创建一个全局的zxid) zk已经使用锁机制对我们zxid保证了足够线程安全问题
Leader发出第一阶段通知带上zxid告诉每个F- ll- wer节点,是否允许同步数据
Leader节点只需要接收超过半数以上的F- ll- wer节点允许同步数据的话,这个时候Leader给F- ll- wer开始同步数据

剩下的节点，会进行版本比对，发现版本不一致的话，会更新节点的数据。
Zookeeper解决分布式事务问题,底层采用2PC两阶段提交协议

Zookeeper集群搭建

1.修改每台zk集群节点zoo.cfg
2.修改myid文件中的数
注意myid不能重复,保证集群唯一
关闭每台节点上的防火墙
注意规律
N=3剩余节点(除宕机之外的节点,或者是启动成功的zk节点)>N(集群总节点数)/2

如果剩余节点数小于这个数,那么zk就起不来
必须要满足过半的原则,zk才能够正常运行

如何保证zk可用,必须满足过半原则
可用节点>集群总节点/2
为什么官方推荐zk集群数量一定要为奇数?
N=5 N=6(N代表zk集群总数)

如果zk集群总数为5的话,能够保证zk可用性问题,最多只能宕机2台(过半原则) 可用节点(3台)>5/2
如果zk集群总数为6的话,能够保证zk可用性问题,最多只能宕机2台(过半原则) 可用节点(4台)>6/2

这就是为什么zk集群官方推荐采用奇数, 因为如果采用奇数,可以节约服务器资源
Zookeeper集群使用- bserver实现扩展
首先Zookeeper中分为三种角色

Leader(领导) Zookeeper集群中的主要节点,负责写的请求操作
F- ll- wer(跟随者) 是领导(Leader)角色1跟随者,除读取操作还可以实现对Leader提议

bserver 如果后期当我们在扩展ZK集群节点时如果角色为F- ll- wer 越来越多会导致选举的时间越来越长,所以- bserver角色和F- ll- wer角色很相似,只是- bServer不能够参加Leader角色选举;

增加- bserver的作用主要在不影响原来本身选举的时间效率,目的是提高客户端读的请求效率;

原来本身只有一个Leader 两个F- ll- wer

原来本身是有三台节点
一个Leader,两个F- ll- wer,Leader宕机,剩余两台F- ll- wer重新选举
后期新增两个节点,总共变成5台节点在Leader未宕机前,不再进行选举
Leader宕机,那么剩余的四台节点会重新进行选举
注意事项:
zk集群在后期扩容的时候,建议不要使用F- ll- wer节点类型,因为可能会导致选举变长

Zookeeper集群中存在一些问题

1.每个节点数据一致性同步问题
2.Zookeeper如何解决分布式一致性问题
通过ZAB协议

底层实现原理

2PC两阶段提交协议
3.后期扩展新增zk节点需要注意哪些问题
如果我们后期zk节点做扩容的时候,如果节点类型是F- ll- wer类型,可能会导致选举时间越来越长,有可能会造成整个zk集群环境不可使用

Zookeeper分为三种节点

Leader类型

领导者类型,负责写的请求和各个节点同步

F- ll- wer类型

跟随者,负责读的请求和转发写的请求以及投票决议
zk节点类型默认就是F- ll- wer类型

bserver类型

观察者类型和F- ll- wer类型大部分特征都是一样的唯一区别就是不能参与选举和投票
为什么要使用- bserver类型

主要是不影响原来本身选举的时间效率
目的是提高客户端查询效率

添加- bserver类型只需要在集群配置信息中对应的节点最后面两个端口号后加上

:- bserver
中心化,去中心化

Eureka是去中心化的注册中心
大家都是平等的
zookeeper是中心化的

最终是要选举出一个Leader出来,其他都是跟随者
Zookeeper-状态 state的属性说明

cZXid
数据节点创建时的事务ID
ctime
数据节点创建的时间
mZxid
数据节点最后一次更新时的事务ID
mtime
数据节点最后一次更新时的时间(m是m- dified的缩写)
pZxid
数据节点的子节点列表最后一次被修改(是子节点列表修改,而不是子节点内容变更)时的事务ID

注意，只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid

cversi- n
子节点的版本号
dataVersi- n
数据节点的版本号
aclVersi- n
数据节点的ACL版本号
ephemeral- wner
如果节点是临时节点,则表示创建该节点会话的Sessi- nId;如果节点是持久节点,则该属性值为0;(ephemeral- wner:临时持有者)
dataLength
数据内容的长度
numChildren
当前节点的子节点个数

为什么我们写的请求必须统一交给Leader 而不是 F- ll- wer节点实现?

因为可以采用借鉴在分布式事务种2PC(两阶段提交协议) 解决分布式数据同步问题
Zookeeper源码分析

Zk选举底层实现原理

状态变更服务器启动的时候,每个Server的状态都是为"选举状态",如果当前的Leader的角色宕机之后,其他的F- ll- wer节点都会才重新进入到选举

2.发起投票的时候,每个Server端都会产生(myid, zxid)投票选举, 系统默认初始化的时候zxid为0, 如果在运行期间每个Server的zxid可能不会相同,这取决于最后一次做更新操作

接收自己投票实现投票 pk
先检查 zxid,谁最大谁就为 Leader
如果zxid都是一样的情况下,myid谁最大谁就是Leader
如果有过半机制已经选举出了Leader,之后启动的节点就不会加入选举

搭建zk集群配置

1.每个zk配置文件需要由myid
2.每个zk配置文件中需要配置所有集群的节点

Eureka 与 Zookeeper 实现的区别

相同点:

Eureka 和 Zookeeper都可以实现服务注册中心

不同点:

Zookeeper保证CP数据一致性问题, 原理:采用ZAB,原子广播协议,当zk在某种情况下出现宕机会重新实现对zk选举新的领导(恢复机制),如果zk选举新的领导时间过长的话,或者投票没有过半数,那么就会导致整个zk集群环境不可用,这也意味着服务注册中心不可用,所以zk必须保证数据一致性
Eureka 保证AP, 设计思想:优先考虑可用性, 完全去中心化的服务注册中心, 每个节点都是均等的;Eureka集群是没有主从之分,几个节点挂掉了也不会影响整个Eureka的使用, Eureka客户端发现连接不可用的时候会自动切换到下一个Eureka的连接, 只要保证Eureka有一个节点存在的话就可以保证整个服务的注册中心可以使用

为什么SpringCl- ud选择Eureka作为注册中心而不是Zookeeper?

首先在这个时候我们要明白一点
服务注册中心, 可以短暂读取以前注册列表信息, 但是不可以接受节点宕机不可用
分区容错CAP概念,为什么不能三者兼顾

CAP理论(http://crazyant.net/2120.html)

在理论计算机科学中，CAP定理（CAP the- rem），又被称作布鲁尔定理（Brewer’s the- rem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
一致性（C- nsistence) （等同于所有节点访问同一份最新的数据副本）可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）分区容错性（Netw- rk partiti- ning）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）
根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。
对于zookeeper来说，它实现了A可用性、P分区容错性、C中的写入强一致性，丧失的是C中的读取一致性。