数据访问：
zookeeper节点上的数据都是以原子的方式读取和写入的。读取时获取节点下的所有数据，写入将替换节点下的所有数据。每个节点都有一个访问控制列表，控制谁可以做什么
zookeeper会话安全的保证，当zookeeper客户端与服务端建立连接时，zookeeper会创建一个会话session发送给客户端。为保证会话安全，服务端会为每一个会话id创建一个密码发送给客户端，并将该密码同步到集群的其他服务器，客户端连接服务器时会通过会话id将该密码发送到服务端进行验证
zookeeper集群的每个节点都存储了全量数据信息，以此来提高读性能，适用于读多写少的场景
zookeeper采用事务日志文件和快照文件两种方式来保证数据安全
ZAB协议：
一、广播：zab协议中，所有的写请求，都由leader来处理，并将更新广播到整个系统
1、leader接收到新的请求后，生成一个全局唯一的64位自增的zxid，通过zxid的大小实现因果有序
2、leader通过队列，将带有zxid的消息作为一个案例（proposal）分发给所有的follower
3、follower接收到提案后（proposal）后，现将proposal写到磁盘，写入成功后向leader发送一个ack消息
4、leader接收到一半以上的follower的ack消息后，向所有的follower发送commit命令，同时本地执行该命令
5、follower接收到commit并执行
zab协议不能终止事务，follower要么回ack给leader，要么抛弃leader，在某一个时刻，follower和leader的状态可能是不一致，因此它不能处理leader挂掉的情况，所以引入恢复来解决这一问题
二、恢复：当服务初次启动、或者leader挂掉，系统自动进入恢复模式，直到选出合法的leader，然后由新leader负责将整个系统同步到最新状态
* 已处理的消息不能丢失
1、选举拥有最大的zxid的节点作为新的leader，
2、新leader将自己事务日志中的proposal但未commit的消息处理完成
3、新leader与follower之间建立一个队列，将自身有但是follower没有的proposal发送给follower，再将这些proposal的commit发送给follower，以此来保证所有的follower都处理了所有的消息
* 被丢弃的消息不能再次出现
考虑这样的一个场景，leader接收到新的消息并生成了一个proposal，但并未将该proposal发送出去就挂掉了，因此所有follower节点上面都没有该proposal信息，因此经过恢复模式选举出新的leader后该消息将被跳过。此时该节点重新恢复并注册成为follower，他保留了被跳过消息的proposal状态，与整个系统状态是不一致的，需要将其删除
阶段锁/三阶段锁
一、两阶段锁：
第一阶段：
1、协调者询问所有参与者节点，是否可以执行提交操作
2、各参与者开始事物执行的准备
3、准备完成，回复协调者可以提交或不可以提交
第二阶段
1、如果所有参与者都回复“可提交”，则协调者发出“正式提交”命令，否则发送“回滚”命令
2、协调者接收各参与者处理结果信息，完成整个事务
二、三阶段提交
第一阶段：协调者向所有参与者节点询问是否可以提交，并接收所有参与者节点的返回信息
第二阶段：协调者向所有参与者节点发送准备提交命令，参与者节点执行准备工作（锁定资源、记录日志等）
第三阶段：协调者向所有参与者节点发送正式提交命令，参与者执行提交并返回执行结果，协调者处理完之后结束整个事务
zookeeper的4种节点类型
1、永久节点
2、永久有序节点
3、临时节点
4、临时有序节点
zookeeper实现分布式锁：
1、在zookeeper上创建有序的临时节点
2、判断当前节点是否是最小节点，如果是，获取锁成功，如果不是，获取锁失败，并在最小节点上注册一个监听器，等待
3、释放锁，删除当前节点
该实现方法存在的问题：惊“群”效应
解决办法：
如果获取锁失败，在当前节点的上一节点上面注册监听器，而不是在最小节点（锁节点）上注册监听器
所以上面的创建思路可修改为：
1、在zookeeper上创建有序的临时节点
2、判断当前节点是否为最小节点，如果是，则获取锁成功，否则获取锁失败。如果获取锁失败，则获取当前节点的上一个节点，并在该节点上注册监听器，等待获取锁
3、释放锁，删除当前节点
zookeeper的角色
1、leader：负责发起投票和写入数据
2、follower：参与learner选举投票，负责接收客户端请求，并相应
3、observer：不参与投票，接收客户端请求，并将写请求转发给leader，保存并同步leader的状态信息
zookeeper的特性
1、最终一致性：zookeeper通过zab协议，保证数据最终是一致的
2、高可用，zookeeper集群只要有一台服务可用，就可以保证消息可以被正确的接收和响应
3、实时性：zookeeper保证客户端将在一个时间间隔范围内获得服务的更新消息，或者服务的失效信息
4、等待无关性：慢或者无效的client不得干预快或有效的client
5、原子性：zookeeper任意节点上的读写是原子性的，要么成功，要么失败。读取时获取节点下的所有数据，删除时删除节点下的所有数据，每个节点都有一个访问控制列表（ACL）
zookeeper的设计不是用于通用数据库或者是大型对象，主要用于协调管理数据。客户端和服务端具有完整性检查功能，确保znode具有小于1M的数据
6、节点数据监控：客户端可以在某个节点上注册监听器，该节点上的任务变化都会实时的通知到客户端
7、临时节点不允许有子节点
8、时序性：zookeeper保证任何zxid1小于zxid2，则事件zxid1一定在zxid2之前发生
zookeeper会话安全
zookeeper客户端与服务端连接成功后，服务端会创建一个会话session，生成一个64位的序列，作为客户端的签名发送给客户端，并创建一个密码和该序列一起发送给客户端，一旦客户端连接到其他服务器上，将通过该序列和密码进行验证