Zookeeper学习总结

最新推荐文章于 2022-10-29 22:41:46 发布

丿路在脚下

最新推荐文章于 2022-10-29 22:41:46 发布

阅读量140

点赞数

分类专栏：架构文章标签： zookeeper

本文链接：https://blog.csdn.net/ywmxyz123456/article/details/118089653

版权

架构专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、理论

CAP理论

分布式系统的CAP理论首先把分布式系统中的三个特性进行了如下归纳：

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否所有节点访问同一份最新的数据

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。

分区容忍性（P）：在网络故障发生的情况下，系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP权衡

CAP理论中根据倾向的不同：

CA – 放弃P：将所有数据都放在一个分布式节点上。这同时放弃了系统的可扩展性。单点集群，
满足一致性，可用性的系统，通常在可扩展性上不太强大（ACID）
AP – 放弃C：这里的放弃一致性是指放弃数据强一致性，而保留数据的最终一致性。系统无法实时保持数据的一致，但承诺在一个限定的时间窗口内，数据最终能够达到一致的状态。
满足可用性，分区容忍性的系统，通常可能对一致性要求低一些（BASE）
CP – 放弃A：一旦系统遇到故障时，受影响的服务器需要等待一段时间，在恢复期间无法对外提供正常的服务。
满足一致性，分区容忍的系统，通常性能不是特别高。

BASE理论

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写。

1. 基本可用

指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用，但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。

2. 软状态

软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。

3. 最终一致性

系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。`最终一致性是弱一致性的一种特殊情况。

二、ZooKeeper简介和特点

ZooKeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能

可构建集群：避免单点故障，3-5台机器就可以组成集群，超过半数正常工作就能对外提供服务

简单数据结构：共享的树形结构，类似文件系统，存储于内存

顺序访问：对于每个请求，zk会分配一个全局唯一的递增编号，利用这个特性可以实现高级协调服务

高性能：基于内存操作，服务于非事务请求，适用于读操作为主的业务场景。3台zk集群能达到13w QPS

ZooKeeper保证分布式一致性特性：

顺序一致性：客户端的更新顺序与它们被发送的顺序相一致。

原子性：更新操作要么成功要么失败

单一视图：客户端无论连接到哪一台服务器，它看到的服务端数据都是一致的。

可靠性：一旦服务器成功应用了一个事务，并完成对客户端的响应，那么该事务引起的服务器状态会被一直保存下来。

持久性：一个更新一旦成功，其结果就会持久存在并且不会被撤销

实时性：ZooKeeper保证在一定时间段内，客户端最终一定能从服务器上读取到最新的数据。

三、ZooKeeper基础核心

服务器角色

在分布式环境中，最典型的集群模式就是Master/Slave（主从模式）。而在ZooKeeper中，并没有沿用MS的概念，而是使用了Leader、Follower和Observer三种角色。

Leader 写+读+选举

ZooKeeper 启动时需要在所有服务器中选举出一个 Leader ，然后让这个 Leader 来负责管理集群。此时，集群中的其它服务器则成为此 Leader 的 Follower 。并且当 Leader 故障的时候，需要 ZooKeeper 能够快速地在 Follower 中选举出下一个 Leader 。Leader是整个集群工作机制中的核心，它的主要职责有以下2个：

事务请求的唯一调度者和处理者，保证事务处理的顺序性。

集群内部各服务器的调度者。

Follower 读+选举

处理客户端非事务请求，转发事务请求给Leader服务器。

参与事务请求Proposal的投票

参与Leader选举投票

Observer 读

和Follower很像，是ZooKeeper自3.3.0之后引入的一个全新的服务器角色。通常用于提升服务器集群非事务处理能力。对于非事务请求，都可以独立处理，而对于事务请求，则会转发给Leader进行处理。Follower和Observer都能提供读服务，唯一的区别在于：Observer机器不参与Leader选举，也不参与写操作“过半写成功”策略。