一文带你了解Zookeeper！

Joy T

于 2024-04-03 08:53:33 发布

阅读量884

点赞数 28

分类专栏：大数据文章标签： zookeeper 分布式云原生

本文链接：https://blog.csdn.net/qq_65052774/article/details/137140358

版权

大数据专栏收录该内容

23 篇文章 0 订阅

订阅专栏

笔记来源：尚硅谷【尚硅谷】大数据技术之Zookeeper 3.5.7版本教程_哔哩哔哩_bilibili /文章一篇文章让你弄懂分布式一致性协议Paxos_paxos协议-CSDN博客/文章Zab（Zookeeper Atomic Broadcast）协议-CSDN博客

带有注册、通知机制的文件系统。

获取当前在线的服务器的列表，并且注册监听。

观察者模式

一个人在干活，另一个人在观察监督，干得好表扬，干得不好批评。

Zookeeper的Leader和Kafka的不同，它最好不要读数据，只负责写数据，而Follower在Zoo中是负责读数据的。Kafka中的Follower是负责备份的，读写操作都是Leader进行。Zoo在这方面类似于Mysql的读写分离机制。
单Leader的设置是为了更方便地保证写操作的一致性，这个设置本质上是Multi-Paxos算法，下文会讲解。
注意是半数以上节点才能存活，为什么建议部署奇数台服务器呢，以5、6台服务器为例：
5台服务器半数为2.5，半数以上的临界值为3台，集群运行至少需要3台服务器，也就是说，挂掉3台就不能服务了。
6台服务器半数为3，半数以上的临界值为4台，集群运行至少需要4台服务器，挂掉3台同样也就不能服务了。
所以无论5台还是6台，挂掉3台集群都会垮掉。如果选择6台服务器集群，垮掉的时候就白白浪费一台服务器了。
每台服务器（Server）的数据都是一致的。（读数据与Follower有关哦！）
客户端的更新请求在Zoo中是FIFO的。
数据量非常小，所以Client能够在短时间内读到实时性数据，Zoo的同步时间非常短。

Zoo和HDFS都是文件系统，存储的数据格式都是树形结构，Zoo的数据量很小（配置信息）。

应用场景

能够实现类似功能的还有Nignx，无论分布式集群内部是如何变化的，Zookeeper都提供统一的域名。

既然都能实现统一命名服务，那么Zookeeper和DNS有什么关系？

Zookeeper和DNS（Domain Name System）虽然都可以用于解决分布式系统中的名称服务问题，但它们的设计目的、使用场景和实现机制有很大的不同。

Zookeeper提供的命名服务功能允许分布式系统中的元素（如服务器节点、资源等）有一个全局唯一的名字。这种功能在某种程度上类似于DNS，但它主要是为了在分布式系统内部解决资源定位和协调问题，而不是为了实现域名到IP地址的映射。
DNS 是互联网上用于将域名转换为IP地址的系统。它是一个分布式的数据库系统，允许用户通过域名访问网站，而不需要记住复杂的IP地址。DNS的主要目的是提供一种机制，使得用户可以使用容易记忆的名称来访问互联网上的资源，而这些名称背后对应的IP地址可以动态变化。

总的来说，关系和区别可以概括为：

设计目的：Zookeeper主要解决分布式系统内部的协调和状态一致性问题，而DNS主要解决的是域名到IP地址的映射问题，以便于人们更容易地访问互联网资源。
使用场景：Zookeeper通常用于分布式系统的内部，提供诸如配置服务、命名服务、同步服务等，而DNS则主要用于互联网上，为用户访问网站提供便利。
实现机制：Zookeeper保证了强一致性，它通过一系列复杂的选举算法和协议（如ZAB协议）来确保数据的一致性。DNS则可能采用缓存等机制来提高解析效率，牺牲了一定的实时性。

虽然Zookeeper可以提供命名服务，使得分布式系统中的服务可以通过统一的名字来访问，这在概念上与DNS提供的功能相似，但它们服务的层面和具体的应用场景是不同的。

统一配置管理：把配置信息放在Zoo中，让多个Client监听，一旦配置信息修改了，那么所有的Client都能在第一时间接收到信息并且更改。

Zoo是把这些信息都放在Znode中，让Client监听Znode，无论是配置信息还是集群节点的信息。如果是集群节点的信息，则Client就是所有的节点，它们注册的目的就是监控别的节点的状态或者让别的节点监控自己的状态。这就是Zoo的统一集群管理。

软负载均衡往往在域名管理的情况下发生，不仅记录域名同时也记录所有集群服务器的信息，每台服务器都有其访问上限，所以需要提供访问数以实现软负载均衡。

选举机制

第一次选举

第一次选举可以把服务器的myid看成是竞选者的年龄，每个人都会投自己一票，但是一旦发现有myid也就是年龄比自己大的人，就会觉得此人经验更为丰富，就把投给自己的票主动投给老者。在出现leader之前大家都是LOOKING状态【也叫数据恢复状态】，但是一旦出现了leader（获得了半数以上的票），则后面更年长（myid更大）的人就表示先让你干leader吧，除非你主动退出（宕机），我们再开始重新选举。

第二次选举

第二次选举机制涉及到Zoo所遵守的Zab协议的崩溃恢复机制，下文会详细介绍。

Zoo的一个大原则是半数以上：只要集群有半数以上的节点存活则集群正常工作，只要集群有半数以上的节点写入某个数据，则立刻向Client发送ack请求。

写数据流程

半数机制：只要有半数写完即可应答。

注意，只有Leader有写权限，所以如果写操作转到Follower，那么会先将写操作转移到Leader上，然后Leader再写自己和Follower。一旦超过半数，则Leader会向一开始的Follower传递ack，然后那个Follower再向Client传递ack。因为原本的Client的写操作是转移到这个Follower的，所以连接是在Client和Follower上，Leader和Client此时没有建立连接。

面试题

半数机制也有缺点，无论什么都需要一半以上的确认，所以通信时间会提高

Paxos【复习归纳版，入门请看本文第一段推荐文章】

1.前提适应条件：非拜占庭错误（没有恶意伪造信息的情况，可以简单理解成没有恶意攻击者）

Paxos协议运行在允许消息重复、丢失、延迟或乱序，但没有拜占庭式错误的网络环境中，它利用“大多数 (Majority)机制”保证了2F+1的容错能力，即2F+1个节点的系统最多允许F个节点同时出现故障。

为什么会有prepare，就是因为存在多个Proposer的时候，会由于网络等问题产生数据的不一致性和延迟，所以需要提前进行prepare声明。Prepare声明的提案值是null。

但我有一个问题就是提案值到底是全局的还是Proposer自身全局的？是全局的，不是自身全局的，不同的Proposer的提案号不一样，否则乱套了。它们是各自按照某一规则递增，不是全局递增。看下面的图就懂了：

如果Acceptor之前接受过值并且现在的prepare值比之前接收的更大，该Acceptor会向新的Proposer发送原来接受过的值，Proposer会选择其中最大的提案号对应的提案值作为自己的提案值。
如果Acceptor之前没有接受过提案值，那么口头答应的prepare中的提案值只是用来拒绝旧者（任何小于当前提案值的prepare请求或者accept请求）或者快速接收新者。但是一旦接收，Acceptor就要存储提案编号和提案值，这个编号和值不仅用来拒绝旧者，还用来更新可能存在的新者的提案值。

时刻提醒自己无论是Prepare还是Accept请求，Proposer都会有半数以上机制（不行的话，会在指定时间或者随机时间段后重发请求）。同时Learner上有两种机制，一个是半数以上机制用来判断是否该提议被半数以上的Acceptor接收，进而判断是否可以学习；一个是Quorum机制作为学习的重要原理机制。

Acceptor同意该提案后发送响应accepted消息给Proposer，并同时发送accepted消息给Learner。Learner判断各个Acceptor的提案结果，如果提案结果已超过半数同意，则将结果同步给集群中的所有Proposer、Acceptor和所有Learner节点，并结束当前提案。

Zab协议

借鉴了Paxos的主备模型（Leader和Follower）系统架构，也就是Multi-Paxos【同样请看上面入精彩文章】，现在Zoo中熟知的Leader就是唯一的主Proposer，只有Leader才能发起提案。Zab协议有关键两点：崩溃恢复和消息广播（崩溃恢复在Paxos中貌似没有涉及）。

消息广播

消息广播时，Leader会将Client的request请求转换成proposal提案。Leader会与每个Follower建立连接，形成FIFO队列，然后再把提案传递。

崩溃恢复

崩溃恢复其实分两种情况，对应之前的两种Leader恢复机制。

恢复的核心点在于：第一，如果恢复之前已经有Leader向Follower传输commit的事务了就表示这个事务已经被处理了，已经向客户端返回ack了但是真正的commit还没进行完Leader就挂掉了，所以不能让这个事务被丢掉，新的Leader必须有这些最新事务的消息记录，然后再查找是否所有的proposal都已经被正确地commit了，如果没有的话就继续把这些proposal给commit，实现数据同步机制。

而且Leader必须要等待Follower将所有尚未同步的事务Proposal都从Leader服务器上同步过，并且应用到内存数据中以后，Leader才会把该Follower加入到真正可用的Follower列表中。【也就是说，既要在新Leader方面保证所有proposal已被commit处理完毕，也要在Follower方面保证所有的proposal都已同步以保证所有Follower的数据一致性】

第二，当 Leader接收到消息请求生成 proposal后就挂了，其他 Follower并没有收到此proposal，因此经过恢复模式重新选了Leader后，这条消息应跳过。注意：

ZXID为全局递增64位，前32位为Epoch。设置更大ZXID的目的就是，事务编号更大的服务器会有最新事务的消息记录，这样就能保证恢复的第一个核心点。
新 Leader选举后其Epoch值会加一。【每参加一次选举，其Epoch都会加一】当老的 Leader作为 Follower接入新的 Leader后，如果其上有旧epoch的未提交的proposal，这些proposal将不会被新的Leader接受，因为它们属于一个已经过时的选举周期。这样，就可以确保所有节点上的数据是一致的，简化了数据恢复和同步的过程。
- 但是注意，老的Leader并不是完全不可能不能参加下一轮选举，不是完全不可能不能当选下一个新的Leader，不是一定会跳过原本Follower没来的及收到的proposal，具体内容请见后文。

CAP

在CAP理论中，分布式系统无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），必须在这三个属性中选择两个。Zookeeper是一个以一致性（C）和分区容错性（P）为设计目标的分布式协调服务，它在网络分区发生时牺牲一定的可用性以保证系统的一致性和分区容错性。

Consiitency数据的一致性，Available服务器的可用性，Partition Tolerance集群分区的容错性。和之前学的一样，可用性是快速恢复，容错性与系统鲁棒性有关。
通常来说系统的分区容错性是必须要完成的，但是一致性和可用性不一定。Zoo保证的是一致性，非常好理解，都用了Zab协议了。
在进行选举的时候，系统服务器都处于LOOKING状态或者数据恢复状态，不会有Leader回复Client，此时集群不可用，不会提供响应服务。

实际上，分区容错性（P）在分布式系统中几乎是一个必须要满足的属性，因为网络分区在分布式环境中是无法完全避免的。网络分区指的是系统的不同部分由于网络故障无法通信，这在任何分布式系统中都可能发生。因此，大多数分布式系统设计的前提是必须能够容忍网络分区。

一致性（C）和可用性（A）的权衡，则取决于系统的具体需求。一些系统可能需要强一致性（如分布式数据库的某些场景，金融交易系统），而另一些系统可能更倾向于保证高可用性（如某些大规模互联网应用，社交网络的某些功能）。

对于其他常见的大数据框架，确实有一些是设计来尽量满足AP理论（即可用性和分区容错性）的，以下是几个例子：

Cassandra：Cassandra是一个高度可扩展的分布式NoSQL数据库，它被设计为优先保证可用性（A）和分区容错性（P）。Cassandra允许用户在一致性和可用性之间进行权衡，通过调整读写操作的一致性级别来达到不同的需求。虽然它可以配置为提供强一致性，但是默认情况下，Cassandra倾向于提供最终一致性以保证高可用性。
DynamoDB：Amazon DynamoDB是一个完全托管的NoSQL数据库服务，它也是设计为满足可用性（A）和分区容错性（P），同时提供最终一致性。DynamoDB通过在多个数据中心复制数据来实现高可用性和分区容错性，客户可以选择使用最终一致性读取或强一致性读取来平衡一致性和可用性的需求。
Couchbase：Couchbase是一个分布式的NoSQL文档数据库，它也是设计来提供高可用性（A）和分区容错性（P）。Couchbase提供了灵活的数据复制选项和最终一致性，允许应用在一致性和可用性之间做出权衡。
Riak：Riak是一个分布式NoSQL键值存储系统，设计目标是提供高可用性（A）和分区容错性（P）。它使用了与Amazon Dynamo相似的设计原理，提供了可调节的一致性模型，允许在最终一致性和强一致性之间进行选择，以适应不同的应用场景。

这些框架和系统通过不同的设计决策和权衡，尽量满足AP的特性，即在网络分区发生时依然保证系统的可用性，同时通过各种机制提供数据的最终一致性，以适应需要高可用性和分区容错性的大数据应用场景。