zookeeper原理与实践(一）----zookeeper的基本功能

Posted 2020-08-20 奋斗中的屌丝

　　我们现在围绕两个问题来学习zookeeper：

• • • 什么是zookeeper？
    • zookeeper基础知识

1. 什么是zookeeper： zookeeper是hadoop下面的一个子项目，是一个分布式协调服务框架，这个解释其实是很抽象的。其实我觉得不用扯这些东西，通过zk的一些实践项目就可以很好的理解什么是zookeeper了。我们通过一个zk的实际例子来了解，基本所有公司都有这样的需求：在使用rpc进行服务调用的时候，我们更不关心现在提供服务的集群入口（比如：一个集群提供同一个服务，但是只有一个入口（进行实际服务调用，负载均衡等操作），并且这个入口会进行主从切换）是哪一个？那么我们应该怎么弄才能再第一时间获取到入口机器的变更呢？这样的需求我们就能使用zookeeper来提供一个命名服务，我们为这个服务提供一个name，并将它注册到zk中，每一次入口变更都会先到zk进行更改。这样就可以完全屏蔽服务集群的入口了。
2. zookeeper基础知识：  

• • • zookeeper组成： 通常集群都存在master/slave架构，比如hadoop。但是zookeeper中却不是这种架构模式，它的组成可以分为三类
      • leader：    集群中的管理者，负责接收客户端的读写操作和消息分发。
      • follower：  集群中leader的随从，负责接收客户端的读操作，并进行leader选举的投票。
      • observe：  用于提高缓解zk的读操作压力，负责接收客户端的都操作，但是不参与leader投票。　
    • 会话： client与server端通过tcp长连接的形式进行通信，建立连接之后通过心跳进行状态检查，同时server端接收client的请求，client端接收server端的watch响应。
    • 数据节点： zookeeper中的数据是按照树状来进行排布的，类似于Linux目录结构，但是不存在文件夹与文件的区别，所有的元素都是节点，我们存储的数据也存放在节点中，节点又可以作为父节点容纳子节点。其中zk的数据节点可进行如下分类：
      • 持久节点： 就是一旦创建就不会因为客户端的连接与否而被删除，除非客户端主动进行删除。
      • 临时节点： 创建节点的生命周期与客户端的生命周期相同，即只能存活在客户端生命周期内。
      • 顺序节点： 就类似与我们平时使用的windows，同样的一个文件放在同一级目录下面会出现后面的编号。就是通过自动添加编号的方式来进行相同目录下不同文件的辨别。
    • 版本：  zookeeper中每个数据节点都存放有我们所需要的数据，并且每个数据都有一个stat数据，这个数据记录了这个znode上的三个版本，分别是version（当前节点的数据版本），cversion（当前znode子节点的版本），avresion（当前znode的ACL版本）。这些版本信息中version版本是保证分布式数据原子性的基础,这个我们后面也会详细的学习。
    • watcher： 我们在使用zk的时候，如果存在这样一种需求，就是客户端会对zk的数据进行缓存以减少对zk集群的访问压力，那么我们需要实时的获取数据的最新版本，那么现在就存在这样一个问题，当服务器端对一个数据进行更改的时候如何通过客户端来获取最新数据。针对这个需求，我们就有必要好好了解一下watcher，其工作的原理就是客户端需要在服务器端针对自己感兴趣的事件（比如：delete）进行watcher注册，当服务器端节点触发这个事件的时候，我们就会通知这些感兴趣的节点来进行数据更新。这就是大致的watcher的过程。
    • ACL： 上面我们提到数据节点的版本时，提到ACL,那么什么是ACL呢？ACL全称是Access Control list，访问控制列表，用来进行数据操作的权限控制。提供了以下几种访问控制权限：
      • create
      • read
      • write
      • delete
      • admin

　　3.　　zookeeper的特征：

• • • 顺序一致性： 指的是同一个客户端发出的一系列请求会严格按照发送的顺序进行执行。
    • 原子性：  主要侧重于zookeeper能够保证在整个zk集群中所有机器都会提交一个事务。注意：这里指的是最终的状态，而不是提交的标准，因为zk commit 事务的时候，只要收到超过一半的节点返回ACK就执行commit。
    • 单一视图：  无论哪一个客户端连接得到的视图都相同，均为同一个视图。
    • 可靠性：  其实我个人对可靠性的理解是允许zk leader节点宕机，zk同样能对外提供服务。而看了以为大牛的博客是这样解释的：可靠性就是说如果一个事务被zk提交，那么事务引起的客户端的变化将会持续下去直到被修改。这个我觉得选择性接收吧。
    • 实时性： zk只能在一定时间内保证数据传递的实时性。