网站栏目设计模板,网站制作是怎么做的,计算机网络营销策划方案,佛山快速排名优化#x1f44f;作者简介#xff1a;大家好#xff0c;我是爱吃芝士的土豆倪#xff0c;24届校招生Java选手#xff0c;很高兴认识大家#x1f4d5;系列专栏#xff1a;Spring源码、JUC源码、Kafka原理、分布式技术原理#x1f525;如果感觉博主的文章还不错的话#xff… 作者简介大家好我是爱吃芝士的土豆倪24届校招生Java选手很高兴认识大家系列专栏Spring源码、JUC源码、Kafka原理、分布式技术原理如果感觉博主的文章还不错的话请三连支持一下博主哦博主正在努力完成2023计划中源码溯源一探究竟联系方式nhs19990716加我进群大家一起学习一起进步一起对抗互联网寒冬 文章目录 Zookeeper是什么怎么去设计leaderfollowerObserver集群组成 安装部署数据结构Zookeeper可以解决那些实际问题有序队列的使用场景同级节点的唯一性节点元数据watcher(监听机制) Zookeeper是什么
将其定义为分布式协调
简单来说就是一个分布式系统下有多个节点每个节点一个请求但是所有的节点只能确定一个请求被通过而这个而通过的是所有节点达成一致的结果。
Google Chubby不开源产品其解决了分布式一致性 我们有多个不同的数据节点如果我们去发起创建订单和扣减库存这两个动作它分别落在不同的节点如果我们要保证数据的一致性可以考虑使用这种方案。其实就是解决分布式场景下达成一致的方式。
我们如何在不可靠的分布式场景中基于某一个提议达成一致这个一致是每一个节点都需要赞同的。
zookeeper是协调分布式下多个节点之间访问顺序的问题所以也叫顺序一致性的中间件。而这个方式有点像实现锁的方式所以zookeeper也能实现分布式锁所以本质上其实就是一种锁的服务。
zookeeper是一种cp模型 怎么去设计
leader
整个集群中的调度节点数据同步
follower 高可用特性 参与投票leader选举的投票数据达成一致的投票 处理客户端的请求提升集群性能这样设计到扩容但是并不是节点越多性能越好因为涉及到了数据同步这里面有一个思想叫做 过半提交 比如当发起一个操作的时候整个集群中至少要有过半的节点认为这是成功的才会成功返回给后端也就会导致follower会参与到这个过程中来。正是因为这样如果盲目的扩容最终就会导致因为过多的follower参与而导致性能下降。
Observer
主要是为了解决 增加follower节点而导致的性能问题其并不需要参与投票但是会参与数据的同步只需要跟leader节点保持一致。简单来说observer服务器只提供非事务请求服务通常在于不影响集群事物事务处理能力的前提下提升集群非事务处理的能力。 如果超过了半数那么就认为事务是成功的那么就返回。 提交事务
如果是过半提交那么就意思着其不是强一致的。如果是强一致的话就必然影响到整个集群的吞吐和性能。
而这个方式就是一个典型的2pc协议。 2pc协议是一个强一致性协议如果想实现2pc在这里的情况就是所有的节点都必须要成功如果有一个失败那么就不行协议定义的是一种规范和标准。所以zookeeper也是使用了2pc的方式只不过它是改进版本的不需要全部成功只需要过半就可以了。
集群组成
怎么要满足过半所以一般是由2n1台server组成每个server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。对于2n1台server只要有n1台大多数server可用整个系统保持可用。我们已经了解到一个zookeeper集群如果要对外提供可用的服务那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信基于这个特性如果向搭建一个能够允许F台机器down掉的集群那么就要部署2*F1台服务器构成的zookeeper集群。
因此3台机器构成的zookeeper集群能够在挂掉一台机器后依然正常工作。一个5台机器集群的服务能够对2台机器怪调的情况下进行容灾。如果一台由6台服务构成的集群同样只能挂掉2台机器。因此5台和6台在容灾能力上并没有明显优势反而增加了网络通信负担。系统启动时集群中的server会选举出一台server为Leader其它的就作为follower这里先不考虑observer角色。
之所以要满足这样一个等式是因为一个节点要成为集群中的leader需要有超过及群众过半数的节点 支持这个涉及到leader选举算法。同时也涉及到事务请求的提交投票
安装部署
部署好后连接发现 这就意味着zookeeper可以存储一些数据在里面可以针对性的对数据进行一些操作。
数据结构 key代表名字value代表值
当dubbo作为服务中心的时候会像zookeeper写入一些信息 它还有临时节点生命周期 、持久化节点、以及有序节点(递增的序列号。
对于其树形结构来说先有父节点再有子节点当然临时节点下不能存在子节点如果临时节点失效了那么子节点怎么办呢。
同级节点下节点名字必须是唯一的。
当了解了节点除了做注册中心还可以做配置中心 所以以上就是 服务注册 和 配置中心的简单示意图。 学到这里其实技术是存在一个取舍的但是功能是可以实现的甚至用数据库来实现其实都可以无非就是一个统一的存储然后做个监听数据的变化那么我们可以监听数据库的变化呀去触发一些动作也没什么问题只不过就是会复杂一些可行性是有的。
剩下的就是针对对应的节点做crud了。
create /nhs
create /nhs/test testcreate [-s] [-e] [-c] [-t ttl] path [data] [acl]
-s表示创建的 znode 为顺序节点即在节点名称后面添加一个自增的数字后缀
-e表示创建的 znode 为临时节点即客户端与 ZooKeeper 断开连接后该节点会自动删除
-c表示创建的 znode 为容器节点即该节点可以拥有子节点
-t ttl表示创建的 znode 有一个 TTLTime To Live值即生存时间超过该时间后节点将被删除
path表示新创建的 znode 的路径
data表示新创建的 znode 的数据内容
acl表示新创建的 znode 的 ACLAccess Control List即访问控制列表。Zookeeper可以解决那些实际问题
有序队列的使用场景
有序节点 全局ID
分布式锁 ZooKeeper中的有序节点能够用于实现分布式锁的主要原因在于其顺序临时节点的特性。当多个客户端尝试创建有序临时节点时ZooKeeper会为每个节点赋予一个唯一的递增顺序号并且客户端创建的节点将按照顺序号从小到大排列。
基于这一特性可以利用ZooKeeper有序节点来实现分布式锁的过程如下
每个客户端需要获取锁时在指定的ZooKeeper节点下创建一个有序临时节点。客户端可以通过获取当前指定节点下所有子节点并且判断自己创建的节点是否为序号最小的节点如果是则表示客户端获得了锁否则客户端需要监听比自己序号小的节点的变化事件。如果前面的节点释放了锁那么其它客户端对应创建的节点会收到通知进而继续尝试获取锁。
分布式队列
同级节点的唯一性
分布式锁
节点元数据
stat /nhs 显示节点的元数据cZxid 0x6 //节点被创建的事务zxid
ctime Sat Sep 05 21:26:15 CST 2020 //创建时间
mZxid 0x6 //修改的事务id
mtime Sat Sep 05 21:26:15 CST 2020 //修改时间
pZxid 0x8 //子节点列表中最后一次被修改的zxid
cversion 1 //子节点版本号 (乐观锁)
dataVersion 0 //当前节点版本号
aclVersion 0 //权限版本号
ephemeralOwner 0x0 //临时节点的所属会话
dataLength 0 //数据的长度
numChildren 1 //子节点数量当前节点watcher(监听机制)
比如服务注册有两个难点
1.服务的管理
2.服务的上下线感知
当我的服务提供者发生上下线变化的时候那么需要去感知移除那个最好的设置方式就是临时节点当服务挂掉的时候不需要去触发什么东西zookeeper会去检测其心跳。 其中service provider是持久化节点。
上图的这个机制就叫做watcher
zookeeper提供了分布式数据的发布/订阅功能zookeeper允许客户端向服务端注册一个watcher监听当服务端的一些指定事件触发了watcher那么服务端就会向客户端发送一个事件通知。
值得注意的是Watcher通知是一次性的即一旦触发一次通知后该Watcher就失效了因此客户端需要反复注册Watcher即程序中在process里面又注册了Watcher否则将无法获取c3节点的创建而导致子节点变化的事件。
配置中心的变更也是这样 配置中心能够应用主要是其 key value结构。
