ZooKeeper详解之二（原理篇）
zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字
服务器角色
- Leader
（1）事务请求的唯一调度和处理者，保证集群事务处理的顺序性
（2）集群内部各服务的调度者
- Follower
（1）处理客户端的非事务请求，转发事务请求给 Leader 服务器
（2）参与事务请求 Proposal 的投票
（3）参与 Leader 选举投票
- Observer
（1）3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力
（2）处理客户端的非事务请求，转发事务请求给 Leader 服务器
（3）不参与任何形式的投票
paxos算法
它是一个基于消息传递的一致性算法，Leslie Lamport在1990年提出，近几年被广泛应用于分布式计算中，Google的Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化
详细可以查看该文章：Zookeeper全解析——Paxos作为灵魂
ZAB协议
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。用于主备选举
ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。
Watch机制-监控
监听数据的变更，会有事件，create、delete、change、children。后续会上代码。
1.get
2.watch
3.callback
分布式锁
zokeeper实现分布式锁
1.抢锁 zk.create();
2.CountDownLatch.await();
3.释放锁 zk.delete();
Redis实现分布式锁
1.setNx，
2.设置过期时间
3.多线程（守护线程）延迟过期
借鉴了Redisson框架实现分布式锁的思路。
分布式锁选型
- 基于ZooKeeper的分布式锁，适用于高可靠（高可用）而并发量不是太大的场景；
- 基于Redis的分布式锁，适用于并发量很大、性能要求很高的、而可靠性问题可以通过其他方案去弥补的场景。