3.ZooKeeper集群架构以及读写原理「第五章 ZooKeeper 原理」「架构之路ZooKeeper理论和实战」

在前面的文章中我们进行了集群的搭建《ZooKeeper集群搭建 - 第354篇》：

ZooKeeper集群搭建 - 第354篇

         这一节我们通过集群的一些原理来对ZooKeeper的集群有一个更深的了解。

一、什么是ZooKeeper

         我们先来回来回顾下ZooKeeper的概念：

         ZooKeeper是一个分布式开源框架，提供了协调分布式应用的基本服务，它向外部应用暴露一组通用服务——分布式同步（Distributed Synchronization）、命名服务（Naming Service）、集群维护（Group Maintenance） 等，简化分布式应用协调及其管理的难度，提供高性能的分布式服务。ZooKeeper本身可以以单机模式安装运行，不过它的长处在于通过分布式ZooKeeper集群（一个Leader，多个Follower），基于一定的策略来保证ZooKeeper集群的稳定性和可用性，从而实现分布式应用的可靠性。核心实现了分布式CAP原理的CP特性。

         核心记住一句话：ZooKeeper 是一个开源的分布式协调服务和分布式数据一致性解决方案。

         误区：ZooKeeper是一个服务注册中心。

         解释：作为服务注册中心，这只是ZooKeeper的一个功能而已，ZooKeeper是协调服务，对于协调服务还有很多其它方向可以进行协调。

（1）更多关于ZK介绍可以参考之前的文章：《什么是 ZooKeeper - 第347篇》

什么是 ZooKeeper - 第347篇

（2）关于分布式CAP原理参考如下文章：《分布式事务的CAP理论》

分布式事务的CAP理论

二、ZooKeeper集群

2.1 ZooKeeper集群图

2.2 ZooKeeper集群中的角色

         Zookeeper 通过复制来实现高可用,以Leader节点为准，Zookeeper的ZNode树上面的每一个修改都会被同步（复制）到其他的Server 节点上面。

2.2.1 Leader

         Leader：在ZooKeeper集群中只有一个节点作为集群的领导者，由各Follower通过Paxos协议选举产生，主要负责接收和协调所有写请求，并把写入的信息同步到Follower和Observer。

         核心的几点是：

（1）有且仅有一个：Leader节点在整个集群中只有一个。

（2）Leader选举：Leader节点是通过Follower节点进行选举而来的（这里要注意的是对于当前的Leader节点一开始也是一个Follower节点，也是可以参与投票的）。

（3）负责读请求：对于读请求的话，Leader也是会处理的。

（4）负责接收和协调所有写请求：这句话可以看出来对于Leader的一个核心作用就是负责 发起与提交写请求。在写入的过程中会做数据的同步到Follower和Observer。

         至于这个写的流程，我们在下面展开说明。

2.2.2 Follower

Follower节点用于接收并且响应Client端的请求，如果是事务操作，会将请求转发给Leader节点；发起投票，参与集群的内部投票。

         核心的几点是：

（1）避免Leader单点故障：每个Follower都作为Leader的储备，当Leader故障时重新选举Leader，避免单点故障。

（2）处理读请求：分摊请求压力，可以直接才处理读请求。

（3）协调写请求：对于事务操作，比如写这样的请求Follower是不直接处理的，而是转发给Leader节点进行处理。

（4）参与投票：Folloer是有参与投票的资格的，对于Leader的需求，数据一致性的保证的投票权（对于Observer节点就没有了）。

2.2.3 Observer

         Observer不参与选举和写请求的投票，只负责处理读请求、并向Leader转发写请求，避免系统处理能力浪费。

         核心的几点是：

（1）不参与投票：不参与选举和写操作的投票。

（2）处理读请求：对于接收到的Client读的请求可以直接处理进行数据的返回。

（3）写请求转发：对于具有事务操作的写请求是转发给Leader进行处理。

         那么Observer存在的价值是什么？请往下看，带你一步一步解开集群的面纱。

2.3为什么要引入Observer角色

         在3.3.0版本新增了角色Observer，那么为什么要引入Observer角色呢？

我们先来看下对于ZooKeeper集群设计要考虑要点：

（1）ZooKeeper 需保证高可用和强一致性。

（2）为了支持更多的客户端，需要增加更多的Server。

（3）Server增多会导致投票阶段延迟增大，影响性能。

ZooKeeper 权衡了伸缩性和高吞吐率，从而引入了Observer角色。它的作用主要表现在以下几个方面：

（1）Observer不参与投票过程，只同步 leader的状态。

（2）Observers 接受客户端的连接，并将写请求转发给 leader节点。

（3）加入更多Observer节点，提高伸缩性，同时还不影响吞吐率。

         简单来理解下就是：提高了读请求的处理能力，不参与投票避免了投票的效率。

2.4 写数据流程

ZooKeeper 的写数据流程主要分为以下几步：

（1） Client 向 ZooKeeper 的 Server1 上写数据，发送一个写请求。

（2）如果Server1不是Leader，那么Server1 会把接受到的请求进一步转发给Leader，因为每个ZooKeeper的Server里面有一个是Leader。这个Leader 会将写请求广播给各个Server，比如Server1和Server2， 各个Server写成功后就会通知Leader。

（3）当Leader收到大多数 Server 数据写成功了，那么就说明数据写成功了。如果这里三个节点的话，只要有两个节点数据写成功了，那么就认为数据写成功了。写成功之后，Leader会告诉Server1数据写成功了。

（4）Server1会进一步通知 Client 数据写成功了，这时就认为整个写操作成功。ZooKeeper 整个写数据流程就是这样的。

购买完整视频，请前往：http://www.mark-to-win.com/TeacherV2.html?id=287