zookeeper

  • 157.zookeeper 是什么？
ZooKeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能、高可用，且具有严格顺序访问控制能力的分布式协调服务。 分布式应用程序可以基于ZooKeeper实现数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁、分布式队列等功能。
  • 158.zookeeper 都有哪些功能？
  • 分布式锁的原理
不同服务器启动的时候，都先去zk的一个持久化节点下创建一个临时有序节点 XXX-0000000001 依次往后排 后面的节点监听前面的节点
排在第一位的获取锁，处理业务逻辑，完成后删除临时节点，后面的节点监听到前面的节点删除，获取锁，依次往后执行
  • 159.zookeeper 有几种部署模式？
单机，集群，伪集群
  • 160.zookeeper 怎么保证主从节点的状态同步？
  • 161.集群中为什么要有主节点？
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，
其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，所以就需要主节点。
  • 162.集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？
可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。
  • 163.说一下 zookeeper 的通知机制？
客户端端会对某个 znode 建立一个 watcher 事件， 当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知， 然后客户端可以根据 znode 变化来做出业务上的改变。
  • 选举
serverId（服务器ID 既 myid）
比如有三台服务器，编号分别是1,2,3。
编号越大在选择算法中的权重越大。
zxid（最新的事物ID 既 LastLoggedZxid）
服务器中存放的最大数据ID。
ID值越大说明数据越新，在选举算法中数据越新权重越大。
选举状态
LOOKING，竞选状态。
FOLLOWING，随从状态，同步leader状态，参与投票。
OBSERVING，观察状态,同步leader状态，不参与投票。
LEADING，领导者状态。
Leader选举有如下两种
  • 第一种：服务器初始化启动的Leader选举。
  • 第二种：服务器运行时期的Leader选举（服务器运行期间无法和Leader保持连接）。
Leader选举的前提条件
  • 只有服务器状态在LOOKING（竞选状态）状态才会去执行选举算法。
  • Zookeeper 的集群规模至少是2台机器，才可以选举Leader，这里以3台机器集群为例。
  • 当一台服务器启动是不能选举的，等第二台服务器启动后，两台机器之间可以互相通信，才可以进行Leader选举
  • 服务器运行期间无法和Leader保持连接的时候。

服务器启动时期的 Leader 选举

在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动后，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下：
(1) 每个Server发出一个投票投给自己。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。
(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下
1、优先检查ZXID。ZXID比较大的服务器优先作为Leader。
2、如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。
(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

服务器运行时期的 Leader 选举

在Zookeeper运行期间，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。选举过程如下：
(1)变更状态。Leader挂后，余下的非Observer服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举流程。
(2)每个Server会发出一个投票。在这个过程中，需要生成投票信息(myid,ZXID)每个服务器上的ZXID可能不同，我们假定Server1的ZXID为123，而Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
(3)接收来自各个服务器的投票。与启动时过程相同。
(4)处理投票。与启动时过程相同，此时，Server1将会成为Leader。
(5)统计投票。与启动时过程相同。
(6)改变服务器的状态。与启动时过程相同。