zookeeper高级应用原理

文章目录

  • 分布式锁
    • 分布式锁-读写锁
    • 分布式锁-Curator实现
    • ZK集群管理
  • zookeeper 集群
    • zookeeper 集群节点个数配置
    • zookeeper 选举
    • ZAB协议
    • zookeeper 选举
    • zookeeper 集群数据读写

分布式锁

  • 分布式锁:在分布式环境下,保护跨进程、跨主机、跨网络的共享资源,实现互斥访问,保证一致性;在zk中,锁就是一个数据节点
  • 普通实现:注册临时节点,谁注册成功谁获取锁,其他监听该节点的删除事件,一旦被删除,通知其他客户端,再次重复该流程;此为最简单的实现,但容易引发羊群效应。这种情况下,大量客户端在短时间内对 ZooKeeper 服务器发起请求,可能超出了服务器的处理能力,导致延迟增加、响应时间变长,甚至导致服务不可用。
  • “羊群效应”(Herd Effect)是指当大量客户端同时对某一事件或资源发起请求时,这些请求会出现在相对较短的时间内集中到服务器上,从而导致服务器过载或性能下降的现象。在ZooKeeper中,这种效应可能会导致严重的性能问题,甚至使整个系统崩溃。

zookeeper高级应用原理_第1张图片

  1. 所有服务要获取锁时都去zookeeper中注册一个临时顺序节点,并将基本信息写入临时节点
  2. 所有服务获取节点列表并判断自己的节点是否是最小的那个,谁最小谁就获取了锁
  3. 未获取锁的客户端添加对前一个节点删除事件的监听
  4. 锁释放/持有锁的客户端宕机 后,节点被删除
  5. 下一个节点的客户端收到通知,重复上述流程

分布式锁-读写锁

  • 共享锁:读锁。如果事务T1对数据对象O1加上共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁,直到该数据对象上的所有共享锁都被释放
  • 排它锁:写锁或独占锁。如果事务T1对数据对象O1加上了排他锁,那么在整个加锁期间,只允许事务T1对O1进行读取或更新操作,其他任务事务都不能对这个数据对象进行任何操作,直到T1释放排他锁
    zookeeper高级应用原理_第2张图片
    可以将临时有序节点分为读锁节点和写锁节点
  1. 对于读锁节点而言,只关心前一个写锁节点的释放。如果前一个写锁释放了,则多个读锁节点对应的线程可以并发地读取数据
  2. 对于写锁节点而言,只关心前一个节点的释放,而不需要关心前一个节点是写锁节点还是读锁节点。因为为了保证有序性,写操作必须要等待前面的读操作或者写操作执行完成。

分布式锁-Curator实现

zookeeper高级应用原理_第3张图片
➢InterProcessMutex:分布式可重入排它锁(可重入可以借助LocalMap存计数器)
➢InterProcessSemaphoreMutex:分布式排它锁
➢InterProcessMultiLock:将多个锁作为单个实体管理的容器
➢InterProcessReadWriteLock:分布式读写锁

ZK集群管理

zookeeper高级应用原理_第4张图片

  • 配置管理:指集群中的机器拥有某些配置,并且这些配置信息需要动态地改变,那么我们就可以使用发布订阅模式把配置做统一的管理,让这些机器订阅配置信息的改变,但是配置改变时这些机器得到通知并更新自己的配置。
  • 服务注册,服务发现:指对集群中的服务上下线做统一管理,每个工作服务器都可以作为数据的发布方,向集群注册自己的基本信息,而让某些监控服务器作为订阅方,订阅工作服务器的基本信息。当工作服务器的基本信息改变时,如服务上下线、服务器的角色或服务范围变更,那么监控服务器可以得到通知并响应这些变化

zookeeper 集群

zookeeper 集群节点个数配置

  • 为什么zookeeper节点推荐配奇数?
  1. 容错率:需要保证集群能够有半数进行投票
    • 2台服务器,至少2台正常运行才行(2的半数为1,半数以上最少为2),正常运行1台服务器都不允许挂掉,但是相对于单节点服务器,2台服务器还有两个单点故障,所以直接排除了。
    • 3台服务器,至少2台正常运行才行(3的半数为1.5,半数以上最少为2),正常运行可以允许1台服务器挂掉
    • 4台服务器,至少3台正常运行才行(4的半数为2,半数以上最少为3),正常运行可以允许1台服务器挂掉
    • 5台服务器,至少3台正常运行才行(5的半数为2.5,半数以上最少为3),正常运行可以允许2台服务器挂掉
  2. 防脑裂:脑裂集群的脑裂通常是发生在节点之间通信不可达的情况下,集群会分裂成不同的小集群,小集群各自选出自己的leader节
    点,导致原有的集群出现多个leader节点的情况,这就是脑裂
    • 3台服务器,投票选举半数为1.5,一台服务裂开,和另外两台服务器无法通行,这时候2台服务器的集群(2票大于半数1.5票),所以可以选举出leader,而 1 台服务器的集群无法选举。
    • 4台服务器,投票选举半数为2,可以分成 1,3两个集群或者2,2两个集群,对于 1,3集群,3集群可以选举;对于2,2集群,则不能选择,造成没有leader节点。
    • 5台服务器,投票选举半数为2.5,可以分成1,4两个集群,或者2,3两集群,这两个集群分别都只能选举一个集群,满足zookeeper集群搭建数目。

zookeeper 选举

  • Paxos算法是基于消息传递且具有高度容错特性的一致性算法,其解决的问题是在分布式系统中如何就某个值(决议)达成一致,paxos是一个分布式选举算法
  • 该算法的三种角色
    ➢ Proposer:提案(决议)发起者
    ➢ Acceptor:提案接收者,可同意或不同意
    ➢ Learners:虽然不同意提案,但也只能被动接收学习;或者是后来的,只能被动接受提案遵循少数服从多数的原则,过半原则。
    zookeeper高级应用原理_第5张图片

ZAB协议

  • ZooKeeper使用的是ZAB协议作为数据一致性的算法, ZAB(ZooKeeper Atomic Broadcast ) 全称为:原子消息广播协议。在Paxos算法基础上进行了扩展改造而来的,ZAB协议设计了支持原子广播、崩溃恢复,ZAB协议保证Leader广播的变更序列被顺序的处理。
    四种状态,其中三种跟选举有关,选举时也是半数以上通过才算通过
    ➢ LOOKING:系统刚启动时或者Leader崩溃后正处于选举状态
    ➢ FOLLOWING:Follower节点所处的状态,同步leader状态,参与投票
    ➢ LEADING:Leader所处状态
    ➢ OBSERVING,观察状态,同步leader状态,不参与投票

zookeeper 选举

zookeeper高级应用原理_第6张图片

zookeeper 集群数据读写

  • 读请求:当Client向zookeeper发出读请求时,无论是Leader还是Follower,都直接返回查询结果

zookeeper高级应用原理_第7张图片

  • 写请求->leader

    • Client向Leader发出写请求,Leader将数据写入到本节点,并将数据发送到所有的Follower节点,等待Follower节点返回,当Leader接收到一半以上节点(包含自己)返回写成功的信息之后,返回写入成功消息给client。
      zookeeper高级应用原理_第8张图片
  • 写请求->follwer

    • Client向Follower发出写请求,Follower节点将请求转发给Leader,Leader将数据写入到本节点,并将数据发送到所有的Follower节点,等待Follower节点返回,当Leader接收到一半以上节点(包含自己)返回写成功的信息之后,返回写入成功消息给原来的Follower,原来的Follower返回写入成功消息给Client。
      zookeeper高级应用原理_第9张图片

你可能感兴趣的:(后端架构知识学习,zookeeper,java-zookeeper)