博客

1、ZooKeeper简介

• 主要用于服务分布式系统，可以用来做：统一配置管理、统一命名服务、实现分布式锁和集群管理
• 在分层的命名空间中ZooKeeper结点存储数据，类似于树结构。
• ZooKeeper是一种C/S架构，其中的结点称为znode，分为四种类型：
  1. 持久化结点：client与server断开后，znode不会被删除
  2. 持久化顺序结点：和持久化结点一样断开后不会被删除，并且依据创建的时间顺序给结点编号
  3. 临时结点：client与server断开后，znode被删除
  4. 临时顺序结点：和临时结点一样断开后会被删除，且依据创建的时间给结点编号

  5. create [-s] [-e] path data  #其中-s为有序节点，-e临时节点

  6. znode结点具有唯一性

• 监听器：监听znode结点的数据变化和监听子节点的增减变化(观察者模式)

2、实现功能的分析

1. 统一配置管理：将配置文件中相同的部分抽象出来形成通用的配置文件，将通用配置文件放在znode节点中，使不同的系统来监听这个配置文件，一旦发生变更就进行及时响应。
2. 统一命名服务：和域名差不多，为一部分资源取一个名字，通过这个名字就可以拿到相应的资源。
3. 如果集群是主从架构模式下，zookeeper还可以实现动态选举Master的功能，znode是临时顺序结点如果挂了就选择最小编号的znode作为Master。
4. 23

3、实现分布式锁

1. 基于数据库来实现分布式锁：对表的字段进行唯一性约束，当前只有一条记录插入成功，其他线程在插入的时候就会插入失败，等价于实现了一个排他锁。（进一步可以撤使用CAS思想来进行优化哈）
   • 每次获得锁都需要访问数据库，可用性是基于数据库的，如果数据库是单点的，那么如果数据挂掉整个业务都不能正常运行
   • 锁是没有失效时间的，一旦解锁失败其他线程永远无法获取锁
   • 锁是不可重入的
   • 锁是非阻塞的，没有获取锁的线程需要进行循环判断，消耗CPU
2. 基于redis实现：使用setnx px。这里nx表示只有不存在键值的时候才会设置成功，px用来设置键的过期时间
   • 获取锁的线程由于某种原因被阻塞掉，到达过期时间后释放掉锁，其他线程获取了锁，改线程在被恢复后将会继续执行以为自己还持有锁
   • 无法重入
   • 在主从模式下，master与slave是异步的，如果客户端A获取了锁但是master在将锁同步到slave之前挂掉了，那么这个锁会被其他客户端获取，此时安全失效。
3. 基于zookeeper的实现：创建持久性结点lock，当客户端需要获取锁时就在lock下面创建临时顺序结点，通过判断自己目前是不是最小的那个结点来是否获取锁，如果不是则监听比自己小1的那个结点。
   • 性能上没有基于redis实现好，因为有结点的创建和销毁。有现成 的框架，有等待锁的队列，提升获取的效率
   • 基于redis的实现性能好，但是需要考虑超时和误删等情况，也没有等待锁的队列需要客户端进行自旋来等待锁。

4、Zookeeper的一致性保证

1. 使用zookeeper atomic broadcast来为zookeeper崩溃进行恢复的原子广播协议
2. 角色和状态：Leader（集群中只允许有一个leader，对客户端提供读写并将数据同步到各个结点）、Follower（提供读的功能，写请求转发给Leader，leader崩溃后参与Leader的选举）和Observer（和Follower一样，但不参与leader选举）。服务状态有：LOOKING（集群中没有leader，服务器进入此状态，目的是查找和选举leader）、LEADING（leader角色）、FOLLOWING(follower角色)和OBSERVING(observer角色)。通过自身的状态来区分自己所属的角色从而完成自己的任务。
3. ZAB的四种状态：
   1. ELECTION：集群进入选举状态，选出leader
   2. DISCOVERY：选出leader，响应leader心跳包并检测leader角色是否更改，此步骤之后的leader才会有作用
   3. SYNCHRONIZATION：集群都确认leader后，就会把leader数据同步到各个结点保证数据一致性
   4. BROADCAST:过渡到广播状态并对外提供服务

参考：

1. 
   https://www.cnblogs.com/austinspark-jessylu/p/8043726.html
   
2. 
   https://mp.weixin.qq.com/s/gphDLJMO3QcRoN3zkco4EA