Zookeeper架构原理和使用场景总结
管动物园的家伙
Zookeeper 是大家耳熟能详的分布式管理中间件，在很多场景下都有很经典的应用。下面主要对zk的架构原理和使用场景做一番总结
Zookeeper特性
最终一致性
保证各个节点服务器数据能够最终达成一致，zk的招牌功能
顺序性
从同一客户端发起的事务请求，都会最终被严格的按照其发送顺序被应用到zk中，这也是zk选举leader的依据之一
可靠性
凡是服务器成功的使用一个事务，并完成了客户端的响应，那么这个事务所引起的服务端状态变更会被一直保留下去
实时性
zk不能保证多个客户端能同时得到刚更新的数据，所以如果要最新数据，需要在读数据之前强制调用sync接口来保证数据的实时性
原子性
数据更新要么成功要么失败
单一视图
无论客户端连的是哪个节点，看到的数据模型对外一致
ZooKeeper架构
下面看一下zk的架构，看看他是怎么保证最终一致性的。
首先按照角色，zk可以分为leader，follower和observer。只有leader才能真正处理事务请求，在整个集群中，当follower和observer收到来自客户端的事务请求时，会转发给leader。当leader处理事务请求的时候，他会向整个集群广播一个提议，也就是我们常说的zab，这个提议的意思就是告诉follower你们要创建，修改，删除某znode，然后follower接受leader的提议之后呢，就会做出相应的操作，并告诉leader操作已经完成。
当leader接受到集群里大多数follower的成功操作的回复之后，（这里大多数指的是集群里机器数的一半，这也是zk为啥要使用奇数台机器凑成集群的一个依据之一），leader认为这次事务被成功处理了，接着再向所有的follower进行通知，告知其进行事务提交，最后会返回客户端一个事务被成功处理的状态。此时如果有落后的follower也就是还没来得及进行事务同步的那些，也会从leader去同步状态，来保证与leader的一致状态
zk集群架构图
zk角色
zk中4种角色的作用：
zk各角色作用
zk写入流程
数据写入最终一致性zab算法。leader负责处理写事务请求，follower负责向leader转发写请求，响应leader发出的提议
zk写入流程
zk选举
首先聊清楚几个概念。
一个是服务器的选举状态，分为looking，leading，following和observer
looking:寻找leader状态，处于该状态需要进入选举流程
leading:leader状态，表明当前服务角色为leader
following:跟随者状态，leader已经选举出，表明当前为follower角色
observer:观察者状态
事务id：zxid
zxid是64位数字，leader分配，全局唯一且递增
zk选主流程
首先每个节点发出一个投票，内容是（myid,zxid）,接受来自各个节点的投票，接着进行投票的处理和统计，最后改变服务器的状态
zk选举过程
zk数据模型znode
znode是zk特有的数据模型，是zk中数据最小单元，znode上能保存数据，通过挂载子节点形成一个树状的层次结构。根由/斜杠开始。
znode层次结构模型
znode节点类型
分为持久节点，临时节点和顺序节点。还可以进行不同节点类型的组合。
znode版本
版本有1.当前数据节点的版本号 2. 当前数据子节点版本号 3.acl权限变更版本号
主要用来通过版本号来实现分布式锁的一些控制
znode watch机制
znode watch机制也是zk的核心功能之一，是配置管理功能的基石。client端通过注册watch对象后，只要相应的znode触发更改，watch管理器就会向客户端发起回调，可借此机制实现配置管理的分布式更新和同步队列等场景。
zk watch机制
主要的总结就到这里，后续会分享一些踩过的坑
