ZooKeeper详解之二（原理篇）

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框架实现分布式锁的思路。

分布式锁选型

1. 基于ZooKeeper的分布式锁，适用于高可靠（高可用）而并发量不是太大的场景；
2. 基于Redis的分布式锁，适用于并发量很大、性能要求很高的、而可靠性问题可以通过其他方案去弥补的场景。