学院网站建设需求分析调研表,人工智能公众号,yw55523can优物入口,网站开发费分摊多少年1、zookeeper是什么#xff1f;
zookeeper能被各个牛逼的中间件项目中所依赖#xff0c;已经说明了他的地位。一出手就是稳定的杀招。zookeeper是什么#xff1f;官网中所说#xff0c;zookeeper致力于开发和维护成为一个高度可靠的分布式协调器。 开局一张图#xff0c;…1、zookeeper是什么
zookeeper能被各个牛逼的中间件项目中所依赖已经说明了他的地位。一出手就是稳定的杀招。zookeeper是什么官网中所说zookeeper致力于开发和维护成为一个高度可靠的分布式协调器。 开局一张图官网就是酷(图片来自官网)。
zookeeper能干的事情很多:
【分布式锁】zookeeper特殊的数据结构和watcher机制让他也能高效的实现分布式锁的功能参考Curactor这款框架分布式锁开箱即用。
【元数据管理】Kafka就是使用zookeeper存储核心元数据。
【分布式协调】zookeeper的watcher机制可以让分布式系统中的各个节点监听某个数据的变化并且zookeeper可以把数据变化反向推送给订阅了的节点例如kafka里面的各个broker和controller之间的协调。
【Master选举】HDFS就是用了zookeeper来保证Namenode的 HA高可用可以保证只有一台成为主。 zookeeper提供了全方位的分布式场景下丰富的功能分布式协调的王者不是虚名。 zookeeper一般是集群部署单机不可能满足上面提到的这些功能的实现。我们一般都是用3-5台机器。每台机器都会在内存存储所有的元数据。划重点zookeeper是基于内存存储的这已经决定了他能实现高吞吐高性能。
zookeeper的内存数据结构就像linux系统的文件系统是一种树形结构每个节点我们叫做znode。zookeeper的节点大致分为三种类别一个是临时节点一个是持久节点还有顺序节点。灵活运用组合这些节点我们在实际开发中能实现各种神奇的功能。 2.zookeeper的架构
既然是分布式领域的一个王者zookeeper具备哪些特性才让他立足呢
集群部署首先部署上肯定是集群部署单机肯不靠谱的。高可用必须要保证高可用一旦集群中的某台机器宕机不能导致数据丢失原子性既然zookeeper走的CP那么一定要保证每次数据写入集群中所有机器必须要要么全部成功要么就全部写入失败。数据一致性同(3)理,数据一致性也要保证无论我客户端连接那一台机器我get某个数据一定是一致的顺序性zookeeper的写入实现了有序的写入这也夯实了自己数据一致性的特性。实时感知zookeeper的watcher机制无疑是一个强大的功能一旦某个数据发生变化感知要实时不然就失去意义了。高性能无论是做什么样的功能超高的读写性能才是根本zookeeper的数据是存储在内存中的这本身就带来了超高的性能。并且同时也能带来超高的并发能力
要做到这些架构设计上是绝对有很多亮点的我们来看看zookeeper的架构设计。 首先我们先来认识一下zookeeper中的几个角色 leader集群启动一定会选择一个节点作为主节点。一个集群中只有一个主节点并且只有主节点接收并处理写请求。 follower从节点首先从节点是不能处理写请求的就算某个客户端连接到从节点提交写请求最终也是转发到主节点leader处理。从节点只负责读请求。 当leader宕机的时候并且当前集群中宕机的数量不超过一半那么集群会重新发起选举从follower中选举出新的leader。 Observer顾名思义观察者一般我们接触zookeeper貌似都不怎么用到它也注意不到他如果你希望你的读并发能力能抗更多的请求你可以选择挂载Observer。它只提供数据读取的服务。
当客户端和zookeeper建立起连接是基于TCP的长连接一个会话session通过心跳机制感知是否断开如果断开只要在sessionTimeout时间内重新连接就能保持住长连接。
zookeeper的数据结构是znode树型结构如上文一样我们每次写入就是构建树节点下的叶子结点。并且创建的节点分为持久节点和临时节点。
持久节点一旦创建会持久化到磁盘哪怕客户端断开下次依然可以读取到。临时节点则不一样一旦客户端断开连接的话就不存在了。和持久节点和临时节点能够组合的还有是否有序在zookeeper的客户端curactor框架中就是基于临时顺序节点实现了分布式锁。
znode的结构长什么样呢我们执行一次get操作可以得到如下这样子的数据结构。 上文说过zookeeper一个很重要的功能是分布式协调这就要依赖于zookeeper的监听回调机制watcher机制当客户端监听一个节点当节点发生变化的时候反向通知客户端如此便可以实现对订阅数据变化的感知并做出响应的处理。基于TCP天然可以实现这样的功能。 3.ZAB是什么
Zookeeper一般都是集群部署那么集群之间各个节点是如何同步数据的呢如何才能保证数据对外的一致性呢
这里就引出了Zookeeper的自己参照一致性协议paxos实现的独有的ZAB协议zookeeper Atomic Broadcastzookeeper原子广播协议。正是通过这个协议zookeeper的集群之间进行数据同步保证数据的强一致性。
首先我们来拍脑袋想一想哪些情况下数据会不一致呢正如上文提到的所有的写请求是转发给leader处理的再加上同步给follower这中间网络通信会出现各种情况甚至leader崩溃follower崩溃这些都会导致数据不一致。
【那么ZAB协议是怎么起到保证一致性的作用呢 】 首先明确的是整个zookeeper集群中的几个角色划分只有leader负责写入数据follower只负责从follower同步数据已经对外提供读取数据。可以说zookeeper实现的就是主备模型。 我们可以认为一次写入就是一次分布式事务从写入请求到leader到follower的数据同步到写入成功返回客户端ACK。这就是分布式事务嘛。 当leader收到一条写入请求这里我们称之为一次事务请求就会将客户端事务请求转换成事务Proposal提议提案)并且将这个事务Proposal发送给所有的Follower节点也就是向所有的follower节点发送数据广播请求。 广播事务Proposal之后leader就要等待所有的Follower服务器的返回(ack请求),划重点在ZAB协议中明确了只要有超过半数的Follower节点正确的返回了ACK就认为本次提案是successful的。那么此时leader就会向所有的Follower服务器广播commit消息对前一次的事务Proposal发起提交。这里我们敏锐的可以感觉到脑海里浮现了一个词语 2PC。这个后面再说。 上面的过程我们可以理解为是一个2PC的过程并且需要过半的机器成功接收到事务Proposal并返回ACK也就是过半写2PC过半写这是ZAB协议的一个核心点。
我们再想想leader从哪里的呢上面讨论的所有问题都是在唯一一台leader存在的情况下那么leader是如何产生的leader宕机了又该怎么办这个是我们接下来要一点点分析的问题。
4.从启动到崩溃ZAB协议做了什么
我们来讨论leader从哪里来既然是最有权势的一个leader没有规矩谁都能当那肯定集群里面的节点都争着要当的这时候我们就要自然是要选举出来的。怎么选这也是ZAB协议里有规定的。
当一个ZK集群启动的时候会进入崩溃恢复模式直到选举出一个leader并且只要过半的Follower机器都和leader机器同步完数据就会退出崩溃恢复模式对外提供服务此时就进入了消息广播模式。 崩溃恢复模式和消息广播模式是zookeeper集群工作的主要俩个模式。 我们接着说leader选举的事情ZAB协议规定leader选举只要过半的机器都投票给某一台机器这台机器就成为leader这里自己也可以投票给自
己。如果leader突然宕机了此时整个集群再次进入崩溃恢复模式重新选举新的leader。
消息广播模式就是集群数据副本传递的主要的策略上文我们也说到了2PC但其实zookeeper还是为了性能做了优化并不是要所有的follower都
返回ACK只要过半数返回ACK就认为本次事务Proposal是写入成功的就可以发起commit请求了。
这里我们其实是有疑惑的这样子zookeeper还是强一致性么毕竟在某个时间点也不是所有的机器都拥有一致的副本啊这么看来也不能说
Zookeeper是实现了强一致性的CP模型这里有个结论最终所有的机器会实现数据副本一致性。
消息广播模式下每次从客户端有一个事务请求过来leader会转化为事务Proposal并且写入本地磁盘还会给每个事务Proposal分配一个全局
唯一的Zxid。 还有个细节当leader向所有的Follower发起事务Proposal时不是就随随便便发送的leader为每一个Follower都维护了一个先进先出的队
列每一个事务Proposal都是按照顺序依次放入保证有序性。当Follower接收到事务Proposal时会将其写入本地磁盘。 这里还有异步解耦的功效也一定程度上提高了事务Proposal的广播速度。那么这里我们还可以说zookeeper实现的是顺序一致性这样看起来更大程度的保证了数据的一致性。 5.Zxid的组成
Zxid其实就是事务id为了保证事务的顺序一致性zookeeper 采用了递增的事务idZxid来标识事务。所有的提案proposal都在被提出的时候加上了 Zxid。
Zxid是64位的数字高32位是任期编号低32位是事务计数器 图中高32位epochZAB协议通过epoch 编号来区分 Leader 周期变化用来标识 leader 关系是否改变每次新 leader 被选出来所有节点的新epoch值为epoch初始值1new epoch值old epoch值1 可以理解成标识当前集群属于哪个leader的统治时期保证了即使旧leader恢复后也没有人再从属于它数据同步后就成了follower因为 follower 只听从当前epoch的 leader 的命令。 图中低32位transactionCount用于递增计数每接收到一条写入请求这个值1。新 leader选举后这个值重置为0。 这样设计的好处在于老的leader挂了以后重启它不会被选举为 leader因此此时它的 zxid 肯定小于当前新的 leader。当老的 leader 作为follower 接入新的leader 后新的leader会让它将所有的拥有旧的 epoch号并且未被COMMIT的 proposal 清除掉。 6.数据不一致了ZAB协议的策略
以上大概描述了ZAB协议下zk集群中leader和follower之间数据副本的同步过程我们在这里稍微消耗脑细胞地想一下有没有什么情况会导致数据不一致
当一个客户端发过来的事务写请求刚刚被leader写到本地还没来得及发起Proposal就宕机了这时候会数据不一致么 【P1】如果一个事务Proposal写入是成功的并且广播给所有的Follower机器也受到了过半机器的ACK此时leader节点挂了并且此时可能leader已经本地commit了那么新的leader选举出来之后这台老的leader重新启动了之后数据会不一致么 【P2】
细细一想不经冷汗这些也是问题啊ZAB要保证自己说到的一致性就必须要解决这俩种情况如何解决呢
关键就在于新leader的选举算法要保证2点
ZAB协议必须保证恢复处理后 【P2】 的需要在所有服务器上都提交成功ZAB必须将恢复后此时已经有新leader了已经跳过 【P1】 重新注册的老leader机器所在的日志中删除掉 【P1】 上文所说的每个事务Proposal分配一个全局唯一的Zxid并且是递增的。再加上任期的概念一切又开始向着一致性的方向迈进了。 如果 leader 选举算法能够保证新选举出来的 leader服务器拥有集群中所有机器最高编号【Zxid最大】的事务 Proposal那么就可以
保证这个新选举出来的 Leader 一定具有已经提交的提案。
毕竟所有提案被COMMIT之前必须有超过半数的 follower ACK即必须有超过半数节点的服务器的事务日志上有该提案的 proposal因此只要有合法数量的节点正常工作就必然有一个节点保 存了所有被 COMMIT 消息的 proposal 状态。而这个节点肯定会拥有最大的Zxid。
综上 ZooKeeper主要依赖 ZAB 协议来实现分布式数据一致性基于该协议ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
