ZoopKeeper

1, Zookeeper Profile

Zookeeper is a highly available, high-performance distributed coordination services, can be used for service discovery, distributed lock, distributed leadership election, configuration management.
All of this foundation are similar to Zookeeper provides a Linux file system tree structure znode (considered to be lightweight memory file system, but only for a small amount of information stored, totally unsuitable for storing large amounts of files or large files) while providing monitoring and notification mechanism for each node;

2, Zookeeper cluster

image.png

3, Zookeeper components

Zookeeper cluster is based on a master copy of the high availability cluster, each server assumes one of three roles;

• Leader: Zookeeper a cluster at the same time there will only be a Leader practical work, he initiates and maintains a heartbeat between each Follower and Observer; all write operations must be completed by the Leader, the Leader will then write to broadcast to other servers

• Follower: Zookeeper a cluster may exist multiple Follower, he will respond Leader heartbeat; Follower can write the request request to deal directly with the client and returns the request, but the request will be forwarded to the Leader write process, and is responsible for processing Leader vote;

• Observer: If you read Zookeeper cluster load is high, or more to the client across the room, you can set some observer servers to improve throughput reading, Observer role and Follower similar, but there are two differences, one did not vote right, that does not participate in the elections does not respond to the proposal, and second, the transaction does not require observer persisted to disk, once the observer is restarted, synchronize the entire name space from the leader

image.png

4, Zookeeper features:

Zookeeper is a composition of multiple server clusters

• A leader, more follower, observer
• Each server keep a copy of the data
• Global data consistency
• Distributed reading flower, wrote implemented by leader
• Update request forwarded by the leader embodiment
• Update request order (the FIFO) , from the same client update request sent in an order of execution
• Data update atomicity, a data update either succeed or fail
• Globally unique data view, client whether it is connected to which server, the data are consistent view
• Real-time , within a certain time frame, client can read the latest data

5, application scenarios

• Sign up for the service and distributed
  in a distributed environment, in order to ensure high availability, usually with the same application or a service provider will deploy more than to reach for other services; and consumers need in these peer servers select one to perform the relevant business logic, typical registration and subscription services, consumer consumption & end end end & production (responsible for balancing similar programs)
  summary: Subscribe to the existence of a relationship between the system
  applies: dubbo the provider and consumer

   

  

  image.png

• Distributed Configuration Center
  distributed distribution center, belonging to the publish and subscribe model, by definition is the publisher will publish data on the node ZK for subscribers to obtain data, centralized management and configuration information dynamically updated
  summary: sensing changes in pull mode ( C >> S) / push mode (S >> C)
  applies: global configuration information, the service address list of the service framework serviced
  attention points: small amount of data, but the data may be updated faster scene
  representative of: the Baidu disconf
  GitHub: https://github.com/knightliao/disconf

• 命名服务
  在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源、服务的地址、提供者等信息；被命名的实体通常是集群中的机器提供的服务地址、进程对象等，这些我们都可以统称他们为名字（Name）
  总结：全局唯一的path、全局唯一性ID
  适用：较为常见的就是一些分布式服务框架中的服务地址列表；通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称
  注意：所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化
  代表：dubbo

image.png

• 分布式通知协调
  Zookeeper中特有的，watcher注册不异步通知机制，能够很好的实现分布式环境下不同系统通知与协调，实现对数据变更的实时处理；
  使用方法通常是不同系统都对ZK上同一个znode节点进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理
  总结：需要双系统协调做一件事情
  适用：调度系统，推送系统，心跳检测等
  需要两方系统一起做的事情，适用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合

• 分布式锁
  分布式锁，主要是得益于zookeeper为我们保证了数据的强一致性。

6、Zookeeper写操作

• 写Leader：通过Leader进行写操作流程
  1、客户端向Leader发起写请求
  2、Leader将写请求以Proposal的形式发给所有Follower并等待应答(ACK)
  3、Follower收到Leader的Proposal后返回ACK
  4、Leader得到过半数的ACK（Leader对自己默认有一个ACK）后，向所有的Follower和Observer发送Commit
  5、leader将处理结果返回客户端

image.png

这里需要注意：
1、Leader并不需要得到Observer的ACK，即Observer无投票权
2、Leader不需要得到所有Follower的ACK，只要收到过半的ACK即可，同时Leader本身对自己有一个ACK。上图中有4个Follower，只需其中两个返回ACK即可，因为 (2+1)/(4+1) > 1/2
3、Observer虽然无投票权，但仍需同步Leader的数据从而在处理读请求时可以返回尽可能新的数据

• 写Follower/Observer：通过Follower/Observer进行写操作

image.png

从上图中可以看出，Follower/Observer均可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理；
除了多了异步请求转发，其他流程与直接写Leader无任何区别

7、Zookeeper读操作

image.png

Leader/Follower/Observer都可直接处理读请求，从本地内存中读取数据并返回给客户端即可；
由于处理读请求不需要服务器之间的交互，Follow/Observer越多，整体可处理的读请求量越大，也即读性能越好

8、Session会话

客户端链接zookeeper集群是通过Session链接（TCP长链接）
客户端链接以后可以对节点（存储在zookeeper上，znode）增删查改操作

9、数据模型Znode

image.png

Znode节点类型：2大类，4种类型，持久、临时、持久有序、临时有序

• PERSISTENT ：持久类型，如果不手动删除，是一致存在的
• PERSISTENT_SEQUENTIAL ：持久有序
• EPHEMERAL ：临时类型，客户端session失效就会随着删除节点，没有子节点
• EPHEMERAL_SEQUENTIAL：临时有序，自增

Znode节点状态

 

image.png

 

image.png

10、ACL（Access Control List）

对znode节点做增删查改时我们可以监控其动作（Watcher机制），还可以对节点设置权限访问

• 内置的ACL schemes：
  world：默认方式，相当于全世界都能访问
  auth：代表已经认证通过的用户（cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户）
  digest：即用户名：密码这种方式认证，这也是业务系统中最常用的
  ip：使用IP地址认证

• ACL支持权限：
  CREATE：能创建子节点
  READ：能获取节点数据和列出其子节点
  WRITE：能设置节点数据
  DELETE：能删除子节点
  ADMIN：能设置权限

11、Watcher 监听

image.png

12、ZAB（原子广播）协议介绍

为了保证写操作的一致性与可用性，Zookeeper专门设计了一种名为原子广播（ZAB）的支持奔溃恢复的一致性协议，基于该协议，Zookeeper实现了一种主从模式的系统架构保持集群中各个副本之间的数据一致性；
根据ZAB协议，所有的写操作都必须通过Leader完成，Leader写入本地日志后再复制到所有的Follower节点；
一旦Leader节点无法工作，ZAB协议能够自动从Follower节点中重新选出一个合适的替代者，即新的Leader，该过程即为领导选举；该leader选举过程，是ZAB协议中最为重要和复杂的过程；

ZAB协议模式：恢复模式 广播模式
当服务启动或者在领导者崩溃后，Zab就进入了恢复密室，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束。状态同步保证了leader和server具有相同的系统状态，一旦leader已经和多数的follower进行了状态同步后，leader就可以广播消息了，即进入广播模式；
这时候当一个server 加入zookeeper服务中，它会在恢复模式下起送，发现leader，并和leader进行状态同步，待到同步结束，它也会参与消息广播；

Zoopkeeper服务一直维持在Broadcast状态，直到leader奔溃了或者leader失去了大部分的followers支持。

广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号（zxid）来保证，所有的提议（proposal）都在被提出的时候加上了zxid，实现中，zxid是一个64位的数字，高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，低32位是个递增计数；

当leader奔溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态

13、ZAB（原子广播）协议详解

在了解ZAB协议具体过程之前不要先了解几个概念。

• 事务
  zookeeper作为一个分布式协调服务，需要leader节点去接受外部请求，转化为内部操作（比如创建，修改，删除节点），需要原子性执行的几个操作就组成了事务，这里用T代表。zookeeper要求有序的处理事务，因此给每个事务一个编号，每进来一个事务编号加1，假设leader节点中进来n个事务，可以表示为T1,T2,T3…Tn。为了防止单点问题导致事务数据丢失，leader节点会把事务数据同步到follower节点中。

• 事务队列
  leader和follower都会保存一个事务队列，用L表示，L=T1,T2,T3…Tn，leader的事务队列是接受请求保存下来的，follower的事务队列是leader同步过来的，因此leader的事务队列是最新，最全的。

• 任期
  在zookeeper的工作过程中，leader节点奔溃，重新选举出新的leader是很正常的事情，所以zookeeper的运行历史中会产生多个leader，就好比一个国家的历史中会相继出现多为领导人。为了区分各个leader，ZAB协议用一个整数来表示任期，我们假设用E表示任期。zookeeper刚运行时选举出的第一个leader的任期为E=1；第一个leader奔溃后，下面选举出来的leader，任期会加1，E=2;一次类推。加入任期概念的事务应该表示为T(E,n)

协议作用

• 选举leader
  每个follower广播自己事务队列中最大事务编号maxId
  获取集群中其他follower发出来的maxId，选取出最大的maxId所属的follower，投票给该follower，选它为leader。
  统计所有投票，获取投票数超过一半的follower被推选为leader
• 同步数据
  各个follower向leader发送自己保存的任期E
  leader,比较所有的任期，选取最大的E，加1后作为当前的任期E=E+1
  将任务E广播给所有follower
  follower将任期改为leader发过来的值，并且返回给leader事务队列L
  leader从队列集合中选取任期最大的队列，如果有多个队列任期都是最大，则选取事务编号n最大的队列Lmax。将Lmax最为leader队列，并且广播给各个follower。
  follower接收队列替换自己的事务队列，并且执行提交队列中的事务。
  至此各个节点的数据达成一致，zookeeper恢复正常服务。
• 广播
  leader节点接收到请求，将事务加入事务队列，并且将事务广播给各个follower。
  follower接收事务并加入都事务队列，然后给leader发送准备提交请求。
  leader 接收到半数以上的准备提交请求后，提交事务同时向follower 发送提交事务请求
  follower提交事务。

14、Leader选举

LOOKING，FOLLOWING，LEADING，OBSERVING

作者：张凯_9908
链接：https://www.jianshu.com/p/00223461e5d9
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。