zookepper是一种分布式协调服务
分布式协调服务:可以在分布式系统中共享配置，协调锁资源，提供命名服务
Zookeeper的数据模型：
类似树结构和文件系统目录，树是由节点组成，zookeeper的数据存储也是基于节点的，这种节点叫Znode，不同的是，zookeeper的引用方式是路径引用，类似于文件路径：
/水果/苹果
/水果/梨子
/蔬菜/白菜
/蔬菜/空心菜
这种层次结构，让每一个Znode节点都有一个唯一的路径。
Znode:包含了数据信息，访问权限，子节点以及一下元数据信息
data: Znode存储的数据信息
ACL:记录了Znode的访问权限，那些人那些ip可以访问本节点
Child:当前节点的子节点引用
Stat:包含了Znode的各种元数据，如事物ID,版本号，时间戳，大小等等
注意：zookeeper是为读多写少的应用场景设计的，Znode并不是用来存储大规模业务数据，而是用于存储状态和配置信息，每个节点的数据大小不能超过1MB
Zookeeper的基本操作和事件通知：
常见的API:
create创建节点
delete删除节点
Exists判断节点是否存在
getData获取一个节点的数据
setData设置一个节点的数据
getChildren获取一个节点下的所有子节点
getData,getChildren,exists是属于读操作，zookeeper客户端在请求读操作时，可以选择是否设置watch
Watch：注册在特定Znode上的触发器。当调用delete , setData, create等方法，也就是Znode发生改变后，会触发Znode上的对应的事件，请求Watch的客户端会接收到异步通知。
Zookeeper的一致性：
为防止单机挂掉的情况，zookeeper自身维护了一个集群。
Zookepper service集群是一主多从结构
在更新数据时，首先更新到主节点（这里的节点不是Znode，是指服务器），在同步到从节点，读取数据时直接从从节点读取。
为保证主从节点数据的一致性，zookeeper采用的是ZAB协议。
ZAB:
Zookepper Atomic BroadCast,有效的解决了集群崩溃恢复，主从数据同步的问题。
ZAB协议定义的三种状态：
Looking：选举状态
Following：follow(从节点)所处状态
Loading：leader(主节点)所处状态
ZXID概念：最大ZXID即本地最新事物编号，包含epoll和计数两部分。
ZAB集群崩溃恢复分三个阶段：
Leader election:选举阶段，此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器ID和最新事务ID（ZXID）。接下来，节点会用自身的ZXID和从其他节点接收到的ZXID做比较，如果发现别人家的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
Discovery:发现阶段，用于在从节点中发现最新的ZXID和事务日志。或许有人会问：既然Leader被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢？这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。所以这一阶段，Leader集思广益，接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。
Synchronization:同步阶段，把Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。自此，故障恢复正式完成
ZAB协议实现写入数据：
写入数据，涉及到ZAB的BroadCast阶段
什么是Broadcast呢？简单来说，就是Zookeeper常规情况下更新数据的时候，由Leader广播到所有的Follower。其过程如下：
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式，先发送Propose广播给Follower。
4.Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。
5.Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower。
Zab协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性。它依靠事务ID和版本号，保证了数据的更新和读取是有序的。
Zookeeper特点：
.顺序一致性：从同一客户端发起的事物请求，最终会严格的按照顺序被应用到zookeeper中去。
.原子性：所有事物请求处理的结果在整个集群的应用情况是一致的，也就是说，要么整个集群的机器应用都成功应用了某一个事物，要么都没有应用。
.单一系统映射：无论客户端连接到那一个zookeeper服务器上，其看到的服务数据模型都是一致的。
.可靠性：一旦一次更改的请求被应用，更改的结果将被持久化，直到被下次更改覆盖
Zookeeper的应用：
1.分布式锁
2.服务注册和发现
3.共享配置和状态信息
Redis的分布式解决方案Codis，就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步节点信息，实现高可用。
网友评论