Zookeeper急速入门-必看核心思想

一、zookeeper作用

先说结论，zookeeper是基于高可用数据容器的分布式服务协调框架。其数据一致性和高可用特性是作为数据容器的特点，包括follower投票和节点数据同步机制，都是为了一件事：存放在这里的数据非常可靠，有许多副本但是有高度数据一致性，不会因为突发的硬件宕机等问题丢失数据，也不会因为集群多副本读到不一致的数据。在此基础上，zookeeper提供作为注册中心注册Znode与节点Watch机制实现调度功能。

二、zookeeper设计思想

1、通过单leader生成zxid保证全局写请求线性一致

由于leader始终只有一个，则由该leader生成的递增zxid必然是唯一的。节点在处理收到写请求时，节点通过zxid便可以分辨写请求的顺序以及是否有缺失zxid写操作未处理，从而实现有序且无缺失地执行写操作。

2、先承诺，后写入，分步写入使节点写操作可受leader控制

leader收到写请求后广播给follower节点，节点先持久化写日志，日志成功写入后即向leader发出ack，此时并未真正实施该写请求，但因为已经持久化日志以用于真正实施，故可以认为发出ack时，节点可以向leader承诺在需要时实施该写操作。当节点收到leader发出的提交命令时，再将日志内容写入内存树数据。通过这种机制，节点的写操作过程便可以受leader控制了。

3、超半数承诺写入，则leader发出提交

当leader广播写请求给所有follower，且收到超过半数的ack成功投票时，则发出提交命令。这里是zookeeper保持数据一致的核心机制，为什么需要半数，为什么不能有任意成功就提交，或者为什么不能全部成功才提交？回答这个问题，可以假设两种极端场景。第一种，假设全部成功才提交。那么由于网络“毛刺”导致频繁的节点失败，则会出现频繁的全局失败，使可用性降低，部分失败节点可以通过恢复机制仍然保持数据一致，所以超过半数成功就提交是最高效的，假设数据对于时效确实非常敏感，开发者可以手动开启sync使得节点发起的读操作时确保和leader数据一致。假设任意成功就提交，甚至只要leader写入就提交，则可能出现节点宕机，写请求未实施而丢失。

4、节点保存和维护数据副本

节点并不是单纯的数据保存和被动接收命令的角色，节点在收到写请求时，需要判断zxid是否有缺漏，如果出现缺漏则会一直阻塞直到当前zxid之前的所有zxid写请求都已提交。此外，如果开发者开启了sync，在处理读请求时，也会保证先完成数据同步。

5、提供注册中心和节点调度框架

有许多框架工具利用了zookeeper，其利用的不是zookeeper上述的1~4点，这些机制对于使用zookeeper的工具来说，比如elasticJob，往往是无感知的，高可用高数据一致性只是其作为分布式框架协调大脑的基础特性，如果zookeeper用于调度真正应用节点的信息随时会丢失，那么其调度能力就是不可靠的。在此之上，zookeeper作为注册中心，提供分布式应用进行Znode注册，同时提供Watch监听机制。elasticJob使用zookeeper为每个定时任务应用注册服务的Znode节点，节点发送心跳保持会话，一旦节点注册的服务宕机，心跳停止，这个Znode临时节点也会释放掉，由此便通过zookeeper实现了对所有节点存续状态的监控。