Zookeeper作为Hadoop大数据生态圈不可或缺的支持组件，在学习阶段也是必学的一个部分。Zookeeper支持分布式服务的实现，在大数据技术架构层面，也是值得去深入理解掌握的。今天的大数据开发学习分享，我们主要来讲讲ZooKeeper的读写机制。
ZooKeeper的读写机制
ZooKeeper的核心思想是，提供一个非锁机制的Wait Free的用于分布式系统同步的核心服务。提供简单的文件创建、读写操作接口，其系统核心本身对文件读写并不提供加锁互斥的服务，但是提供基于版本比对的更新操作，客户端可以基于此自己实现加锁逻辑。如下图所示。
ZK集群服务
Zookeeper是一个由多个Server组成的集群，该集群有一个Leader，多个Follower。客户端可以连接任意ZooKeeper服务节点来读写数据，如下图所示。
ZK集群中每个Server，都保存一份数据副本。Zookeeper使用简单的同步策略，通过以下两条基本保证来实现数据的一致性：
①全局串行化所有的写操作
②保证同一客户端的指令被FIFO执行（以及消息通知的FIFO）所有的读请求由Zk Server本地响应，所有的更新请求将转发给Leader，由Leader实施。
ZK组件
ZK组件，如下图所示。ZK组件除了请求处理器（Request Processor）以外，组成ZK服务的每一个Server会复制这些组件的副本。
ReplicatedDatabase是一个内存数据库，它包含了整个Data Tree。为了恢复，更新会被记录到磁盘，并且写在被应用到内存数据库之前，先被序列化到磁盘。
每一个ZK Server，可服务于多个Client。Client可以连接到一台Server，来提交请求。读请求，由每台Server数据库的本地副本来进行服务。改变服务器的状态的写请求，需要通过一致性协议来处理。
作为一致性协议的一部分，来自Client的所有写请求，都要被转发到一个单独的Server，称作Leader。ZK集群中其他Server称作Follower，负责接收Leader发来的提议消息，并且对消息转发达成一致。消息层处理leader失效，同步Followers和Leader。
ZooKeeper使用自定义的原子性消息协议。由于消息传送层是原子性的，ZooKeeper能够保证本地副本不产生分歧。当leader收到一个写请求，它会计算出当写操作完成后系统将会是什么状态，接着将之转变为一个捕获状态的事务。
ZK性能
ZooKeeper被应用程序广泛使用，并有数以千计的客户端同时的访问它，所以我们需要高吞吐量。我们为ZooKeeper设计的工作负载的读写比例是2：1以上。然而我们发现，ZooKeeper的高写入吞吐量，也允许它被用于一些写占主导的工作负载。ZooKeeper通过每台Server上的本地ZK的状态副本，来提供高读取吞吐量。因此，容错性和读吞吐量是以添加到该服务的服务器数量为尺度。写吞吐量并不以添加到该服务的机器数量为尺度。
关于大数据开发学习，ZooKeeper的读写机制，以上就为大家做了基本的介绍了。Zookeeper在现有的大数据技术生态来说，仍然是不可忽视的一个部分，而学习阶段，也应该相应做好准备。
网友评论