互联网架构-分布式协调工具Zookeeper-056：Zookeeper一致性原理

最新推荐文章于 2023-06-23 13:54:21 发布

竞风之翼

最新推荐文章于 2023-06-23 13:54:21 发布

阅读量233

点赞数

分类专栏：蚂蚁课堂第5期视频笔记文章标签： java zookeeper

本文链接：https://blog.csdn.net/u012425860/article/details/113402157

版权

蚂蚁课堂第5期视频笔记专栏收录该内容

59 篇文章 24 订阅

订阅专栏

056：Zookeeper一致性原理

1 Zookeeper集群可能会存在的问题

课程内容
1.分布式系统中网络分区脑裂概念
2.Zookeeper集群使用Observer实现扩展
3.ZookeeperZAB原子消息广播协议实现原理
4.ZAB原子消息广播与Paxos算法区别
5.Zookeeper与Eureka实现注册原理区别

Zookeeper集群中存在一些问题
1.每个节点数据一致性同步问题
2.Zookeeper如何解决分布式一致性问题 ZAB协议底层两阶段提交协议
3.后期扩展新增zk节点需要注意哪些问题

2 Zookeeper集群使用Observer实现扩展

原来本身只有三台节点，一个Leader，两个Follower，Leader宕机剩余两台Follower重新选举；
后期新增了两台Follower，总共变成五台节点，Leader宕机剩余四台Follower重新选举。后期zk节点做扩容的时候，如果节点的类型为Follower类型，可能会导致选举时间越来越长，有可能会造成整个zk集群环境不可使用。
注意：zk集群在后期扩容的时候，建议不要使用Follower节点类型，因为可能会导致选举变长。

Zk中分为三种节点：
Leader类型领导类型负责写的请求，和各个节点同步；
Follower类型跟随者负责读的请求和投票决议；
Observer类型观察者和Follower大部分特征都是一样的，唯一区别就是不能参与选举和投票。
为什么要使用Observer类型，主要不影响原来本身选举的时间效率、目的是提高客户端查询效率；

3 如何在Zookeeper集群配置Observer

Observer相关配置
所有节点在zoo.conf 文件中修改

server.1=192.168.206.53:2888:3888
server.2=192.168.206.54:2888:3888
server.3=192.168.206.55:2888:3888
server.4=192.168.206.56:2888:3888:observer

测试结果：
在这里插入图片描述

4 Zookeeper客户端连接集群地址

Zk集群是由多个Server节点组成的一个集群，只有一个Leader节点，其他节点类型都是Follower/Observer类型。
1.每个Follower节点保存了Leader节点副本数据；
2.全局保证数据一致性问题；
3.分布式读写分开，写的请求统一交给Leader实现，Follower或者Observer节点主要实现读的操作；
注意：如果连接的节点类型为Observer或者Follower情况下做写的操作的时候直接转发到Leader实现写。

Zkclient客户端使用
连接客户端
cd /usr/local/zookeeper/bin/
./zkCli.sh -server 192.168.206.53:2181

public class Test001 {

    //参数1 连接地址
    private static final String ADDRES = "192.168.206.53:2181,192.168.206.54:2181,192.168.206.55:2181";
    // 参数2 zk超时时间
    private static final int TIMEOUT = 5000;
    public static void main(String[] args) {
        ZkClient zkClient = new ZkClient(ADDRES, TIMEOUT);
        zkClient.createPersistent("/meite_mayikt2021");
        zkClient.close();
    }
}

测试结果：
在这里插入图片描述

5 ZAB原子广播协议两种模型

ZAB原子广播协议
核心是保证各个节点数据同步问题，ZAB协议中两种模式，分别为恢复模式(选主)和广播模式(同步)。
恢复模式：leader的节点宕机之后，会在剩余节点选出新的leader；
广播模式：解决每个节点数据同步问题；

6 Zookeeper集群解决数据一致性原理

Zookeeper数据如何实现同步
当zk中发出一个事务请求的时候，这时候Leader节点就会创建一个全局的事务id(zxid)。
只有在做写的时候才会有事务，所以Zxid指的就是写的请求业务操作。
在这里插入图片描述
Zookeeper数据实现同步原理：
1.Leader处理写事务请求(创建一个全局的zxid)；zk底层已经使用锁的机制对zxid保证了线程安全问题；
2.Leader发出第一阶段通知带上zxid告诉每个Follower节点是否允许可以同步数据；
3.Leader节点只需要接收超过半数以上的Follower允许同步数据，这时候Leader给每个Follower开始同步数据。
Zk底层解决分布式事务问题，采用2pc两阶段提交协议；

为什么写的请求必须统一交给leader而不是follower节点实现？
因为可以借鉴在分布式事务中2pc（两阶段提交协议）解决分布式数据同步问题。
在这里插入图片描述 ZooKeeper -状态信息 Stat 的属性说明
cZxid 数据节点创建时的事务ID
ctime 数据节点创建时的时间
mZxid 数据节点最后一次更新时的事务ID
mtime 数据节点最后一次更新时的时间
pZxid 数据节点的子节点列表最后一次被修改（是子节点列表变更，而不是子节点内容变更）时的事务ID
cversion 子节点的版本号
dataVersion 数据节点的版本号
aclVersion 数据节点的ACL版本号
ephemeralOwner 如果节点是临时节点，则表示创建该节点的会话的SessionID；如果节点是持久节点，则该属性值为0
dataLength 数据内容的长度
numChildren 数据节点当前的子节点个数

7 Zookeeper集群策略zxid的作用

ZooKeeper选举实现原理
1.状态变更服务器启动的时候，每个Server的状态都是为“选举状态”，如果当前的leader角色宕机后非Observer角色的节点都会重新进入到选举流程；
2.发起投票的时候,每个Server端都会产生(myid,zxid)投票选举。
Myid：服务节点上的id
Zxid：Zxid取决于每个节点最后一次做事务写的请求保存的id，数据越新，zxid越大；系统默认初始化的时候zxid为0。
3.接受自己投票实现投票pk
先检查zxid，谁最大谁就是leader；
如果zxid都是一样，myid谁最大谁就是leader；
如果有过半机制已经选举出了leader，之后启动的节点不会加入选举。

(1,100),(2,100),(3,100)顺序启动，为什么会选出了2 为leader？
Zxid相等，(1,100),(2,100)选举选出(2,100)为leader。
(1,103),(2,102),(3,101),为什么会选出了1为leader？
优先比较zxid，(1,103) zxid >(2,102)zxid

8 分布式情况下网络抖动脑裂概念

网络分区脑裂：
在集群的情况下，一般只会选举一个master节点、其他节点都是为从节点，那么如果网络发生抖动或者部分节点无法实现通讯，就会导致部分节点重新实现选举，这样就会存在多个master节点。

9 分布式架构中CAP与Base理论

CAP理论
1.C Consistency在分布式系统中所有数据备份，在同一时刻必须要一致；
2.A Availability在集群中部分节点宕机之后，任然能够保证服务可用；
3.P Partition tolerance分区容错，在分布式系统中网络分区存在的脑裂的问题，部分Server与集群其他节点失去联系，无法组成一个群体。该问题一定是存在的。
当前技术环境下，不能同时满足CA（服务节点宕机之后，很难保证同一时刻同步问题），但是可以满足CP或者AP。

BASE理论
Basically Available（基本可用）：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用；
Soft-state（软状态/柔性事务）：即允许系统在不同节点间副本同步的时候存在延时；
Eventual Consistency（最终一致性）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。
BASE理论是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。
核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。

10 Eureka与Zookeeper作为注册中心区别

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

为什么SpringCloud选择Eureka作为注册中心而不是Zookeeper？
服务注册中心可以短暂读取以前服务注册列表信息，但是不可以接受节点宕机不可用。