最近在学习zookeeper,发现zk真的是一个优秀的中间件。在分布式环境下,可以高效解决数据管理问题。在学习的过程中,要深入zk的工作原理,并根据其特性做一些简单的分布式环境下数据管理工具。本文首先对zk的工作原理和相关概念做一下介绍,然后带大家做一个简单的分布式配置中心。

zookeeper介绍

  zookeeper是一个分布式协调框架,主要是解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理、分布式锁等。

zookeeper使用

查看节点

  # ls /path

创建节点

  #create /path data

修改节点

  #set /path data

删除节点

  #delete /path

获取节点数据

  #get /path

zookeeper C/S连接状态

  1)KeeperState.Expired:客户端和服务器在ticktime的时间周期内,是要发送心跳通知的。这是租约协议的一个实现。客户端发送request,告诉服务器其上一个租约时间,服务器收到这个请求后,告诉客户端其下一个租约时间是哪个时间点。当客户端时间戳达到最后一个租约时间,而没有收到服务器发来的任何新租约时间,即认为自己下线(此后客户端会废弃这次连接,并试图重新建立连接)。这个过期状态就是Expired状态

  2)KeeperState.Disconnected:就像上面那个状态所述,当客户端断开一个连接(可能是租约期满,也可能是客户端主动断开)这是客户端和服务器的连接就是Disconnected状态

  3)KeeperState.SyncConnected:一旦客户端和服务器的某一个节点建立连接(注意,虽然集群有多个节点,但是客户端一次连接到一个节点就行了),并完成一次version、zxid的同步,这时的客户端和服务器的连接状态就是SyncConnected

  4)KeeperState.AuthFailed:ookeeper客户端进行连接认证失败时,发生该状态

zookeeper工作原理

  文件系统 + 监听机制

文件系统特点

  同一个目录下文件名称不能重复,同样zookeeper也是这样的,zookeeper中统一叫作znode。znode节点可以包含子znode,也可以同时包含数据。znode只适合存储非常小的数据,不能超过1M,最好都小于1K。

znode节点类型

  临时节点(EPHEMERAL):客户端关闭zk连接后清除

  永久节点(persistent):持久化节点,除非客户端主动删除

  有编号节点(Persistent_sequential):自动增加顺序编号的znode持久化节点

  临时有编号(Ephemral_ sequential):临时自动编号设置,znode节点编号会自动增加,但是会客户端连接断开而消失。分布式锁用的是这个类型的节点。

  注:EPHEMERAL 临时类型的节点不能有子节点,对于zk来说,有几个节点数据就会存储几份。

监听机制

  客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、节点删除、子目录节 点增加删除)时,zookeeper会通知客户端。

  

  1、客户端启动时向zookeeper服务器注册信息

  2、客户端启动同时注册一系列的Watcher类型的监听器到本地的WatchManager中

  3、zookeeper服务器中节点发生变化后,触发watcher事件后通知给客户端,客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。

zookeeper监听的事件类型

  EventType.NodeCreated:当znode节点被创建时,该事件被触发。

  EventType.NodeChildrenChanged:当znode节点的直接子节点被创建、被删除、子节点数据发生变更时,该事件被触发。

  EventType.NodeDataChanged:当znode节点的数据发生变更时,该事件被触发。

  EventType.NodeDeleted:当znode节点被删除时,该事件被触发。

  EventType.None:当zookeeper客户端的连接状态发生变更时,即KeeperState.Expired、KeeperState.Disconnected、KeeperState.SyncConnected、KeeperState.AuthFailed状态切换时,描述的事件类型为EventType.None。

zookeeper下server工作状态

  LOOKING:当前server不知道leader是谁,正在选举

  LEADING:当前server即为选举出来的leader

  FOLLOWING:leader已经选举出来,当前server是follower

ZAB协议

  ZAB 协议全称:Zookeeper Atomic Broadcast(Zookeeper 原子广播协议)。
  ZAB 协议作用:解决分布式数据管理一致性。
  ZAB 协议定义:ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 消息广播 协议。
  基于该协议,Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间数据一致性。

消息广播

  zookeeper集群采用主从(leader-follower)模式保证服务高可用。leader节点可读可写,follower节点只读,这种模式就需要保证leader节点和follower节点的数据一致性。对于客户端发送的写请求,全部由 Leader 接收,Leader 将请求封装成一个事务 Proposal,将其发送给所有 Follwer ,然后,根据所有 Follwer 的反馈,如果超过半数成功响应,则执行 commit 操作(先提交自己,再发送 commit 给所有 Follwer)。

  注:上述中有一个概念:两阶段提交过程(分布式系统中数据一致性经常会涉及到的方案)。follower节点是可以处理写请求的,会转发给leader节点。leader节点通过消息广播(二阶段提交)同步写操作到follower节点,保证数据一致性。

  zookeeper中每个事务都对应一个ZXID(全局的、唯一的、顺序的)。ZXID 是一个 64 位的数字,其中低 32 位可以看作是一个简单的递增的计数器,针对客户端的每一个事务请求,Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID,并从该 ZXID 中解析出对应的 epoch 值,然后再对这个值加一。

崩溃恢复

  即如果在消息广播的过程中,leader死掉了,如何保证数据的一致性问题。

  假设两种异常情况:
  1、一个事务在 Leader 上提交了,并且过半的 Folower 都响应 Ack 了,但是 Leader 在 Commit 消息发出之前挂了。
  2、假设一个事务在 Leader 提出之后,Leader 挂了。

  考虑到上述两种异常情况,Zab 协议崩溃恢复要求满足以下两个要求:
  1)确保已经被 Leader 提交的 Proposal 必须最终被所有的 Follower 服务器提交。
  2)确保丢弃已经被 Leader 提出的但是没有被提交的 Proposal。

  崩溃恢复主要包含:leader选举 和 数据恢复。

  leader选举:

  1、要求 可用节点数量 > 总节点数量/2  。注意 是 > , 不是 ≥。

     2、新选举出来的 Leader 不能包含未提交的 Proposal(新选举的 Leader 必须都是已经提交了 Proposal 的 Follower 服务器节点) 、新选举的 Leader 节点中含有最大的 zxid(可以避免 Leader 服务器检查 Proposal 的提交和丢弃工作。如果zxid相同,选择server_id【zoo.cfg中的myid】最大的。)

  数据恢复

  1、上面讲过了ZXID的高 32 位代表了每代 Leader 的唯一性,低 32 代表了每代 Leader 中事务的唯一性。同时,也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。

  2、基于这样的策略:当 Follower 链接上 Leader 之后,Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对,比对结果要么回滚,要么和 Leader 同步。

zookeeper集群脑裂

  集群的脑裂通常是发生在节点之间通信不可达的情况下,集群会分裂成不同的小集群,小集群各自选出自己的master节点,导致原有的集群出现多个master节点的情况。

zookeeper集群节点数(奇数or偶数?)

  只要我们清楚集群leader选举的要求(可用节点数量 > 总节点数量/2  。注意 是 > , 不是 ≥),我相信很容易明白奇数节点集群相比偶数节点的集群有更大的优势。

  1、发生脑裂(分成2个小集群)的情况下,奇数节点的集群总会有一个小集群满足可用节点数量 > 总节点数量/2,所以zookeeper集群总能选取出leader。

  2、在容错能力相同的情况下,奇数集群更节省资源。还是要清楚leader选举的要求哈,举个列子:3个节点的集群,如果集群可以正常工作(即leader选举成功),至少需要2个节点是正常的;4个节点的集群,如果集群可以正常工作(即leader选举成功),至少需要3个节点是正常的。那么3个节点的集群和4个节点的集群都有一个节点宕机的容错能力。很明显,在容错能力相同的情况下,奇数节点的集群更节省资源。

zookeeper和eureka对比

  在分布式系统领域有个著名的 CAP定理(C- 数据一致性;A-服务可用性;P-服务对网络分区故障的容错性,这三个特性在任何分布式系统中不能同时满足,最多同时满足两个)。

  zookeeper基于CP,即任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就 是在极端环境下,zookeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。至于zookeeper为啥不能保证服务的高可用,大家可以想一下发生脑裂后无法选取leader、选取leader过程中丢弃某些请求。当网络出现故障时,剩余zk集群server会发起投票选举新的leader,但是此过程会持续30~120s,此过程对于高并发来说十分漫长,会导致整个注册服务的瘫痪,这是不可容忍的。

  Eureka基于AP,不会有类似于ZooKeeper的选举leader的过程,采用的是Peer to Peer 对等通信,没有leader/follower的说法,每个peer都是对等的;客户端请求会自动切换 到新的Eureka节点;当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中。当Eureka节点接受客户端请求时,所有的操作都会在节点间进行复制(replicate To Peer)操作,将请求复制到该 Eureka Server 当前所知的其它所有节点中。至于为啥Eureka不能保证数据一致性,源于Eureka的自我保护机制:如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 。

  2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用) 。

  3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中。

  因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

总结

  以上是对zookeeper的工作原理和相关概念的一些整理,希望能对大家认识zookeeper有所帮助。下一篇文章开始基于zookeeper做一个简单的分布式配置中心,敬请期待!!!

参考链接

  https://blog.csdn.net/pml18710973036/article/details/64121522

  https://www.cnblogs.com/stateis0/p/9062133.html

  https://www.jianshu.com/p/2bceacd60b8a

  

  

基于zookeeper实现分布式配置中心(一)的更多相关文章

  1. 基于zookeeper实现分布式配置中心(二)

    上一篇(基于zookeeper实现分布式配置中心(一))讲述了zookeeper相关概念和工作原理.接下来根据zookeeper的特性,简单实现一个分布式配置中心. 配置中心的优势 1.各环境配置集中 ...

  2. Zookeeper笔记之基于zk的分布式配置中心

    一.场景 & 需求 集群上有很多个节点运行同一个任务,这个任务会有一些可能经常改变的配置参数,要求是当配置参数改变之后能够很快地同步到每个节点上,如果将这些配置参数放在本地文件中则每次都要修改 ...

  3. 基于ZK构建统一配置中心的方案和实践

    背景: 近期使用Zk实现了一个简单的配置管理的小东西,在此开源出来,有兴趣的希望提出您的宝贵意见.如果恰巧您也使用或者接触过类似的东西, 也希望您可以分享下您觉得现在这个项目可以优化和改进的地方. 项 ...

  4. SrpingCloud 之SrpingCloud config分布式配置中心

    Config架构 当一个系统中的配置文件发生改变的时候,我们需要重新启动该服务,才能使得新的配置文件生效,spring cloud config可以实现微服务中的所有系统的配置文件的统一管理,而且还可 ...

  5. spring cloud 入门系列七:基于Git存储的分布式配置中心

    我们前面接触到的spring cloud组件都是基于Netflix的组件进行实现的,这次我们来看下spring cloud 团队自己创建的一个全新项目:Spring Cloud Config.它用来为 ...

  6. 基于winserver的Apollo配置中心分布式&集群部署实践(正确部署姿势)

    基于winserver的Apollo配置中心分布式&集群部署实践(正确部署姿势)   前言 前几天对Apollo配置中心的demo进行一个部署试用,现公司已决定使用,这两天进行分布式部署的时候 ...

  7. spring cloud 入门系列七:基于Git存储的分布式配置中心--Spring Cloud Config

    我们前面接触到的spring cloud组件都是基于Netflix的组件进行实现的,这次我们来看下spring cloud 团队自己创建的一个全新项目:Spring Cloud Config.它用来为 ...

  8. SpringCloud搭建分布式配置中心(基于git)

    1.简介 Spring Cloud Config.它用来为分布式系统中的基础设施和微服务提供集中化的外部配置支持,分为服务端和客户端两个部分. 其中服务端也称为分布式配置中心,他是独立的微服务应用,用 ...

  9. 分布式配置中心 携程(apollo)

    1.传统配置文件与分布式配置文件区别 传统配置文件:如果修改了配置文件,需要重新打包发布,重新发布服务,而且每个环境的变更配置文件,比较繁琐. 分布式配置文件:将配置文件注册到配置中心上去,可以使用分 ...

随机推荐

  1. mysql系列之8.mysql高可用 (keepalived)

    环境: centos6.5_x64 准备: 两台mysql机器 主1 master:  192.168.32.130 主2 backup:  192.168.32.131 VIP: 192.168.3 ...

  2. EF学习和使用(三)Code First

    Code First模式我们称之为"代码优先"模式.从某种角度来看.其实"Code First"和"Model First"区别并非太明显. ...

  3. UITableViewCell的多选操作

    版权声明:本文为博主原创文章.未经博主同意不得转载,转载需加上原博客链接. https://blog.csdn.net/panyong4627/article/details/37902207 - ( ...

  4. Java for LeetCode 083 Remove Duplicates from Sorted List

    Given a sorted linked list, delete all duplicates such that each element appear only once. For examp ...

  5. 基于ajax的登录

    验证码 当登录一个网站的时候往往会有验证码. python生成随机验证码,需要使用到 PIL 模块 安装 : pip3 install pillow 1. 创建图片        我们现在写的验证码属 ...

  6. Swift 烧脑体操(二) - 函数的参数

    前言 Swift 其实比 Objective-C 复杂很多,相对于出生于上世纪 80 年代的 Objective-C 来说,Swift 融入了大量新特性.这也使得我们学习掌握这门语言变得相对来说更加困 ...

  7. P4298 [CTSC2008]祭祀

    P4298 [CTSC2008]祭祀 传递闭包跑一遍按联通建图 $(1)$最长反链长度=最小链覆盖=n-最大匹配 $(2)$定义作为最大匹配出现在左端点的集合为$S$,作为最大匹配出现在右端点的集合为 ...

  8. webpack热替换原理

    前期准备: const path = require('path'); const HtmlWebpackPlugin= require('html-webpack-plugin'); const C ...

  9. JSON.stringify出现 "Converting circular structure to JSON"

    JSON.stringify()  我们很熟悉了,将一个对象转换为json形式的字符串. 但是如果你在浏览器控制台中输出 JSON.stringify(window). 如果期望输出一段文字, 可能会 ...

  10. JS工具函数汇总

    备注:http://phpjs.org/  这个站点把PHP常用的方法用js实现了,推荐一下 1.从数组中随机获取几个不重复项 //从一个给定的数组arr中,随机返回num个不重复项 function ...