zookeeper的一些常见知识点
Zookeeper架构图
数据一致性
zookeeper是通过zab协议来保持数据一致性。
ZAB协议包括2个阶段：leader election阶段和Atomic broadcast阶段。
- leader election阶段：当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，(使用选举算法，少数服从多数)让所有的服务器都恢复到一个正确的状态。
- Atomic broadcast阶段：当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leader election的过程就结束了，将进入Atomic broadcast的过程。Actomic broadcast同步leader和follower之间的信息，保证leader和follower具备相同的系统状态。
zookeeper角色
zookeeper包括leader、learner、client角色，其中learner又包含follower和observer角色
Zookeeper核心
zookeeper的核心是原子广播，这个机制保证了各个server之间的同步，实现这个机制的协议叫做Zab协议。
Zab协议有两种模式：
- 恢复模式（选主）：当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。
- 广播模式（同步）：广播模式保证了leader和learner具有相同的系统状态。
事务的顺序一致性
zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
server工作状态
- LOOKING：当前Server不知道leader是谁，正在搜寻
- LEADING：当前Server即为选举出来的leader
- FOLLOWING：leader已经选举出来，当前Server与之同步
Zookeeper 数据模型
- 层次化的目录结构，命名符合常规文件系统规范
- 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
- 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
- Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
- 客户端应用可以在节点上设置监视器
- 节点不支持部分读写，而是一次性完整读写
Zookeeper节点
- znode的类型在创建时确定并且之后不能再修改，znode有两种类型
- 短暂的（ephemeral）：客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
- 持久的（persistent）：不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
- Znode有四种形式的目录节点
- PERSISTENT（持久的）
- EPHEMERAL(暂时的)
- PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）
- EPHEMERAL_SEQUENTIAL（暂时化顺序编号目录节点）
路由和负载均衡
通过注册相应的watcher，服务消费者能够第一时间获知服务提供者机器信息的变更。利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。Zookeeper集群间通过Zab协议，服务配置信息能够保持一致，而Zookeeper本身容错特性和leader选举机制，能保证我们方便地进行扩容。
通过Zookeeper来实现服务动态****器上线与下线的动态感知，扩容方便，容错性好，且无中心化结构能够解决之前使用负载均衡设备所带来的单点故障问题。只有当配置信息更新时服务消费者才会去Zookeeper上获取最新的服务地址列表，其他时候使用本地缓存即可，这样服务消费者在服务信息没有变更时，几乎不依赖配置中心，能大大降低配置中心的压力。
参考