Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目
为什么需要 Zookeeper
比如我们搭建了一个数据库集群，里面有一个Master，多个Slave，Master负责写，Slave只读，我们需要一个系统，来告诉客户端，哪个是Master。
ZooKeeper致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务
ZooKeeper五大特性
ZooKeeper一般以集群的方式对外提供服务，一个集群包含多个节点，每个节点对应一台ZooKeeper服务器，所有的节点共同对外提供服务，整个集群环境对分布式数据一致性提供了全面的支持，具体包括以下五大特性：
从同一个客户端发起的请求，最终将会严格按照其发送顺序进入ZooKeeper中
所有请求的响应结果在整个分布式集群环境中具备原子性，即要么整个集群中所有机器都成功的处理了某个请求，要么就都没有处理，绝对不会出现集群中一部分机器处理了某一个请求，而另一部分机器却没有处理的情况
无论客户端连接到ZooKeeper集群中哪个服务器，每个客户端所看到的服务端模型都是一致的，不可能出现两种不同的数据状态，因为ZooKeeper集群中每台服务器之间会进行数据同步
一旦服务端数据的状态发送了变化，就会立即存储起来，除非此时有另一个请求对其进行了变更，否则数据一定是可靠的
当某个请求被成功处理后，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能从服务端上读取到最新的数据状态，即ZooKeeper保证数据的最终一致性
ZooKeeper集群角色
在分布式系统中，集群中每台机器都有自己的角色，ZooKeeper没有沿用传统的Master/Slave模式（主备模式），而是引入了Leader、Follower和Observer三种角色
集群通过一个Leader选举过程从所有的机器中选举一台机器作为”Leader”，Leader能为客户端提供读和写服务
Leader服务器是整个集群工作机制的核心，主要工作：
事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
集群内部各服务器的调度者
顾名思义，Follower是追随者，主要工作：
参与Leader选举投票
处理客户端非事务请求 - 即读服务
转发事务请求给Leader服务器
参与事务请求Proposal的投票
Observer是ZooKeeper自3.3.0版本开始引入的一个全新的服务器角色，充当一个观察者角色，工作原理和Follower基本是一致的，和Follower唯一的区别是Observer不参与任何形式的投票
处理客户端非事务请求 - 即读服务
转发事务请求给Leader服务器
不参与Leader选举投票
参与事务请求Proposal的投票
所以Observer可以在不影响写性能的情况下提升集群的读性能
原子广播协议 - Zab
ZooKeeper并非采用经典的分布式一致性协议 - Paxos，而是参考了Paxos设计了一种更加轻量级的支持崩溃可恢复的原子广播协议-Zab（ZooKeeper Atomic Broadcast）。
ZAB协议分为两个阶段 - Leader Election（领导选举）和Atomic Broadcast（原子广播）
当集群启动时，会选举一台节点为Leader，而其他节点为Follower，当Leader节点出现网络中断、崩溃退出与重启等异常情况，ZAB会进入恢复模式并选举产生新的Leader服务器，当集群中已有过半机器与该Leader服务器完成数据状态同步，退出恢复模式
当领导选举完成后，就进入原子广播阶段。此时集群中已存在一个Leader服务器在进行消息广播，当一台同样遵循ZAB协议的服务器启动后加入到集群中，新加的服务器会自动进入数据恢复阶段
ZOOKERPER配置详见教程
Zookeeper
分别启动Zookeeper
/opt/module/apache-zookeeper-3.5.7-bin/bin/zkServer.sh start
查看状态
/opt/module/apache-zookeeper-3.5.7-bin/bin/zkServer.sh status
启动客户端
/opt/module/apache-zookeeper-3.5.7-bin/bin/zkCli.sh
网友评论