分布式服务治理 Zookeeper 简介

Zookeeper 简介

分布式系统定义及面临的问题

Zookeeper 最为主要的使用场景,是作为分布式系统的分布式协同服务。

我们将分布式系统定义为:分布式系统是同事跨越多个物理主机,独立运行的多个软件所组成的系统。类比一下,分布式系统就是一群人干活,人多力量大,每个服务器的算力是有限的,但是通过分布式系统,由n个服务器组成起来的集群,算力可以试无限扩张的。

优点显而易见,人多干活快,并且互为备份,但是缺点也很明显。我们可以想象一下,以一个小研发团队开发软件为例,假设我们有一个5人的项目组,要开始一个系统的开发,项目组将面临如下问题:

在这里插入图片描述

图中列举的就是项目组将要面临的问题,这些问题在我们日常工作中也是天天发生,并没感觉有多么复制,因为我们人类的大脑是个超级计算机,能够灵活应对这些问题,而且现实中信息的交换不依赖网络,不会因网络延迟或者中断,出现信息不对等,而且现实中对以上问题的处理其实并不严谨,从而也引发了很多问题。想一下,项目中是不是出现过沟通不畅造成任务分配有歧义?是否由于人员离职造成任务进行不下去,甚至要联系离职人员协助?是不是出现过任务分配不合理?类似这种问题,肯定会发生在项目中,在显示世界里,我们可以人为去协调,即使出错了,还可以人工去补错。但是在计算机的世界,一切要保证严谨,以上问题要做到尽可能不要发生。因此分布式系统必须采用合理的方式解决以上的问题。

实际上要想解决这些问题并没有那么复杂,我们仅需要做一件事就可以了—— 让信息在项目组成员中同步。如果能做到信息同步,那么每个人在干什么,大家都是清楚的,做到什么程度也是清晰的,无论谁离职也不会产生问题,分配的工作,能够及时清晰的同步给每个组员,确保每个组员收到的任务分配没有冲突。

分布式系统的协调工作就是通过某种方式,让每个节点的信息能够同步和共享。这依赖与服务进程之间的通信。通信方式有两种:

  • 通过网络进行信息共享

    这就像现实中,开发leader在会上把任务传达下去,组员通过听leader命令或者看leader的邮件知道自己要干什么。当任务分配有变化时,leader会单独告诉组员,或者再次召开会议。信息通过人与人之间的直接沟通完成传递。

  • 通过共享存储

    这就好比开发leader按照约定的时间和路径,把任务分配表放到了svn上,组员每天去svn上拉取最新的任务分配表,然后干活。其中svn就是共享存储。更好一点的做法是:当svn文件版本更新时,触发邮件通知,每个组员再去拉取最新的任务分配表。这样做会更好,组员都能第一时间得到消息,从而让自己手中的任务分配表永远是最新的。这种方式依赖于中央存储。整个过程如下所示:

在这里插入图片描述

Zookeeper 如何解决分布式系统面临的问题

Zookeeper 对分布式系统的协调,使用是第二种方式,共享存储。其实共享存储,分布式应用也需要和存储进行网络通信。

实际上,通过Zookeeper 实现分布式协同的原理,和项目组通过SVN同步工作任务的例子是一样的。Zookeeper 就像是SVN,存储了任务的分配、完成情况等共享信息。每个分布式应用的节点就是组员,订阅这些共享信息。当主节点对某个从节点的分工信息作出改变时,相关订阅的从节点得到zookeeper的通知,取得自己最新的任务分配。完成工作后,把完成情况存储到 zookeeper,主节点订阅了该任务的完成情况信息,所以将得到zookeeper的完工通知。

在这里插入图片描述

Slave 节点想要获取 zookeeper 的更新通知,需事先在关心的数据节点上设置观察点

大多数分布式系统中出现的问题,都源于信息的共享除了问题。如果各个节点间信息不能及时共享合同部,那么就会在协作过程中产生各种问题。zookeeper解决协同问题的关键,就是在于保证分布式系统信息的一致性。

zookeeper 的基本概念

zookeeper 是一个开源的分布式协调服务,其设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一些简单的接口提供给用户使用。zookeeper 是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现诸如 数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁和分布式队列 等功能。

基本概念

① 集群角色

通常在分布式系统中,构成一个集群的每一台机器都有自己的角色,最典型的集群就是 Master / Slave 模式(主从模式),此情况下把所有能够处理写操作的机器成为 Master 机器,把所有通过异步复制方式获取最新数据,并提供读服务的机器称为 Slave 机器

而在zookeeper 中,它没有沿用传统的 Master/Slave 概念,而是引入了 Leader、Follower、Observer 三种角色。

zookeeper 集群中的所有机器通过 Leader 选举来选定一台被称为 Leader 的机器,Leader 服务器为客户端提供读和写服务。除Leader 外,其他机器包括 Follower 和 Observer也能提读服务,Follower 和 Observer 唯一的区别是 Observer 不参与 Leader 选举过程,不参与写操作的过半写成功策略,因此 Observer 可以在不影响写性能的情况下提升集群的性能。

② 会话(Session)

Session 指客户端会话,一个客户端连接是指客户端和服务端之间的一个 TCP 长连接,zookeeper 对外的服务端口默认为 2181,。客户端启动的时候,首先会与服务器建立一个 TCP 连接,从第一次连接建立开始,客户端会话的生命周期也开始了,通过这个连接,客户端能够心跳检查与服务器保持有效的会话,也能够向 zookeeper 服务器发送请求并接受响应,同时还能通过该连接接受来自服务器的 Watch 时间通知。

③ 数据节点(Znode)

在谈到分布式的时候,我们通常说的 “节点” 是指组成集群的每一台机器。然而在zookeeper中,“节点” 分为两类,第一类同样是指构成集群的机器,我们称之为机器节点;第二类则是指数据模型中的数据单元,我们称之为数据节点—— ZNode。zookeeper将所有数据存储在内存中,数据模型是一棵树(ZNode Tree),由斜杠(/)进行分割的路径,就是一个 ZNode,例如 /app/path1 。每个 ZNode 上都会保存自己的数据内容,同时还会保存一系列属性信息。

④ 版本

上面我们提到,zookeeper 的每个ZNode 上都会存储数据,对于每个ZNode,zookeeper都会为其维护一个叫做 stat 的数据结构,Stat 记录了这个ZNode的三个数据版本,分别是 version(当前ZNode的版本)、cversion(当前ZNode子节点的版本)、aversion(当前ZNode的ACL版本)

⑤ Watcher(事件监听器)

Watcher(事件监听器),是zookeeper中一个很重要的特性,zookeeper 允许用户在指定节点上注册一些 Watcher,并且在一些特定时间触发的时候,zookeeper 服务端会将事件通知到感兴趣的客户端,该机制是 zookeeper 实现分布式协调服务的重要特性

⑥ ACL

zookeeper 采用ACL(Access Control Lists)策略来进行权限控制,其定义了如下五种权限:

  • CREATE:创建子节点的权限
  • READ:获取节点数据和子节点列表的权限
  • WRITE:更新节点数据的权限
  • DELETE:删除子节点的权限
  • ADMIN:设置节点ACL的权限

其中需要注意的是,CREATE 和 DELETE 这两种权限都是针对子节点的权限控制

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值