3、 zookeeper案例

分布式配置

如果有一些服务器，在启动的时候需要一些配置，以及它们在运行的时候，有一些配置被变更了，它们要第一时间获知，这时候成本应该降到最低，所以这时候要用zookeeper，也就说把这些配置数据存到zk里面去，所有的客户端只要去watch这些数据或者get时候，如果当这些配置数据发生修改时候，就会触发watch回调。

分布式锁

比如有两个不同的物理节点，它们有各自的线程，两个节点的线程不能异步执行，只能同步执行。比如两个同时要访问某一个资源，那只能其中一个节点的线程来访问资源，不能同时访问，所以它们要去获得一把锁，作为分布式锁的方式有很多，不过很多方式都太麻烦，目前最合适作为分布式锁的是zookeeper，zk是集群高可用的，并且视图统一的（就是数据同步的，不管连哪个节点都可以），还是高可用的（恢复快）。

1. 两个服务要去争抢zk这个分布式锁，那肯定只能有一个可以获取到锁，
2. 获得锁的在如果在还没有执行完一块逻辑时候，这个服务挂了，那就会变成死锁，所以要创建临时节点，因为临时节点伴随客户端的session，也就是客户端断开连接之后，锁就自动消失了。
3. 如果获得锁的执行成功了，服务没正常执行完，就释放锁。
4. 问题是锁被释放后，其他服务怎么知道锁被释放了？？
   比如一直在死循环里隔一段时间就去发送心跳包，不好的地方就是会有延迟，不能立马就知道锁被释放这件事。如果访问zk的客户端很多，都来发送心跳包访问zk，那对zk也会造成压力。
   或者使用事件监听回调函数的方式（watch），这样可以解决延迟问题，立马就知道锁被释放了，但是这样如果获取锁的服务很多，zk要给很多的客户端服务都要回调通知，还是对zk产生了很大的压力。
   所以可以用序列节点 + watch的方式，很多服务要抢锁的时候，给这些服务的序列号作为一个节点在zk里面，回调的时候，去回调前一个，也就是最小序列的获得锁，一旦最小的释放锁，比如第一个序列的服务，zk只给第二个发送回调事件。