Learning Zookeeper systematically

深入理解Zookeeper

引用自《zookeeper分布式过程协同技术讲解》

在计算机诞⽣之后很长的⼀段时间⾥，⼀个应⽤服务是在⼀个独⽴的 单处理器计算机上运⾏⼀段程序。时⾄今⽇，应⽤服务已经发⽣了很⼤的 变化。在⼤数据和云计算盛⾏的今天，应⽤服务由很多个独⽴的程序组 成，这些独⽴的程序则运⾏在形形⾊⾊、千变万化的⼀组计算机上。

相对于开发在⼀台计算机上运⾏的单个程序，如何让⼀个应⽤中多个 独⽴的程序协同⼯作是⼀件⾮常困难的事情。开发这样的应⽤，很容易让 很多开发⼈员陷⼊如何使多个程序协同⼯作的逻辑中，最后导致没有时间 更好地思考和实现他们⾃⼰的应⽤程序逻辑；又或者开发⼈员对协同逻辑 关注不够，只是⽤很少的时间开发了⼀个简单脆弱的主协调器，导致不可 靠的单⼀失效点

ZooKeeper的设计保证了其健壮性，这就使得应⽤开发⼈员可以更多关 注应⽤本⾝的逻辑，⽽不是协同⼯作上。ZooKeeper从⽂件系统API得到启 发，提供⼀组简单的API，使得开发⼈员可以实现通⽤的协作任务，包括 选举主节点、管理组内成员关系、管理元数据等。ZooKeeper包括⼀个应⽤ 开发库（主要提供Java和C两种语⾔的API）和⼀个⽤Java实现的服务组 件。ZooKeeper的服务组件运⾏在⼀组专⽤服务器之上，保证了⾼容错性和 可扩展性。

当你决定使⽤ZooKeeper来设计应⽤时，最好将应⽤数据和协同数据独⽴开。⽐如，⽹络邮箱服务的⽤户对⾃⼰邮箱中的内容感兴趣，但是并不 关⼼由哪台服务器来处理特定邮箱的请求。在这个例⼦中，邮箱内容就是 应⽤数据，⽽从邮箱到某⼀台邮箱服务器之间的映射关系就是协同数据 （或称元数据）。整个ZooKeeper服务所管理的就是后者

1. 核心概念

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

• 集群角色
  • 通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群就是Master/Slave模式（主备模式），此情况下把所有能够处理写操作的机器称为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器为Slave机器
  • 而在Zookeeper中，这些概念被颠覆。他没有沿用传统的Master/Slave概念，而是引入了Leader、Follower、Observer三种角色。Zookeeper集群中的所有机器通过Leader选举来选定一台被程为Leader的机器，Leader服务器为客户端提供读写服务，除Leader外，其他机器包括Follower、Observer都提供读服务，唯一的区别在于Observer不参与Leader选举过程，不参与写操作的过半写成功策略，因此Observer可以在不影响写性能的情况下提升集群的性能。
• 会话（session）
  • Session指客户端会话，一个客户端连接是指客户端和服务器端之间的一个TCP长连接，Zookeeper对外的服务端口默认为2181
  • 客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的周期也开始了，通过这个连接，客户端能够心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接收响应，同时还能够通过该连接接受来自服务器的Watch事件通知。
• 数据节点（Znode）
  • 数据节点称之为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（Access Control Lists）
  • Zookeeper采用ACL策略来进行权限控制，其定义了如下五种权限：
    • CREATE:创建子节点的权限
    • READ:获取节点数据和子节点列表的权限
    • WRITE:更新节点数据权限
    • DELETE:删除子节点的权限
    • ADMIN:设置节点ACL的权限
  • 其中需要注意的是，CREATE和DELETE这两种权限都是针对子节点的权限控制

1.1 举个例子

• 外卖平台：美团、饿了吗
• 我是商家，我需要先入住平台（美团 or 饿了吗），然后你作为客户，可以在美团这个平台上，对我，进行点餐，完成一次交易
• 这次交易由三人完成：我（Server端）---> 美团（zk）<---- 你（Client）
  • 也就是说zk作为一种协调服务的存在，在后续学习中，我们还会了解到大数据生态圈，那时候zookeeper（动物管理员），Hadoop（大象），Hive（蜜蜂），Pig（猪）等技术相互之间可以通过zk进行管理

1.2 工作机制

• Zookeeper从设计模式角度来理解：是一个基于观察者模式（一个人干活，有人盯着他）设计的分布式服务管理框架
• 它负责 存储 和 管理 大家都关心的数据
  • 然后接受观察者的注册，一旦这些数据的发生变化
  • Zookeeper就将负责通知已经注册的那些观察者做出相应的反应
  • 从而实现集群中类似Master/Slave管理模式
• Zookeeper = 文件系统 + 通知机制

1.3 特点

• 先来聊一下 分布式和集群的区别？
  • 无论分布式和集群，都是很多人在做事情。具体区别如下：
  • 例如：我有一个饭店，越来越火爆，我得多招聘一些工作人员
    • 分布式：招聘1个厨师，1个服务员，1个前台，三个人负责的工作不一样，但是最终目的都是为饭店工作
    • 集群：招聘3个服务员，3个人的工作一样
• 对于zk来说有如下几个特点，这几个特点也会贯穿我们整个学习的进度
  1. 是一个leader和多个follower来组成的集群（狮群中，一头雄狮，N头母狮）
  2. 集群中只要有半数以上的节点存活，Zookeeper就能正常工作（5台服务器挂2台，没问题；4台服务器挂2台，就停止）
  3. 全局数据一致性，每台服务器都保存一份相同的数据副本，无论client连接哪台server，数据都是一致的
  4. 数据更新原子性，一次数据要么成功，要么失败（不成功便成仁）
  5. 实时性，在一定时间范围内，client能读取到最新数据
  6. 更新的请求按照顺序执行，会按照发送过来的顺序，逐一执行（发来123，执行123，而不是321或者别的）

1.4 数据结构

• ZooKeeper数据模型的结构与linux文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode（ZookeeperNode）。
• 每一个ZNode默认能够存储1MB的数据（元数据），每个ZNode的路径都是唯一的
  • 元数据（Metadata），又称中介数据、中继数据，为描述数据的数据（data aboutdata），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、
  • 资源查找、文件记录等功能

1.5 应用场景

提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等

1.5.1 统一命名服务

• 在分布式环境下，通常需要对应用或服务进行统一的命名，便于识别
• 例如：服务器的IP地址不容易记，但域名相比之下却是很容易记住

1.5.2 统一配置管理

• 分布式环境下，配置文件做同步是必经之路

• 1000台服务器，如果配置文件作出修改，那一台一台的修改，运维人员肯定会疯，如何做到修改一处就快速同步到每台服务器上

• 将配置管理交给Zookeeper

  1、将配置信息写入到Zookeeper的某个节点上

  2、每个客户端都监听这个节点

  3、一旦节点中的数据文件被修改，Zookeeper这个话匣子就会通知每台客户端服务器

1.5.3 服务器节点动态上下线

• 客户端能实时获取服务器上下线的变化
• 在美团APP上实时可以看到商家是否正在营业或打样

1.5.4 软负载均衡

• Zookeeper会记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户请求（雨露均沾）
• 都是自己的孩子，得一碗水端平