Zookeeper
2021-05-06 18:15:33 11 举报AI智能生成
zookeeper架构
作者其他创作
大纲/内容
概念：
集群
三种角色
Leader
负责处理集群的写操作，并发起投票，只有超过半数的节点同意后 才会提交写请求
follower
处理读请求，响应结果。转发写请求到Leader，在选举leader过程中参与投票
observer
没有投票权的follower。主要书协助follower处理读请求。在读请求负载很高的时候才会处理
两种模式
恢复模式
当服务启动或者领导崩溃后，zk进入恢复状态，选举leader, leader选出后，将完成leader和其他机器的数据同步，当大多数Server完成和leader的同步后，恢复模式结束
广播模式
一旦leader已经和多数的follower进行了状态同步后，进入广播模式。进入广播模式后，如果有新加入的机器，会自动从leader中同步数据。leader在接收客户端请求后，会生成事务提案广播给其他的机器，有超过半数以上的follower同意该提议后，再提交事务
leader选举算法
启动过程
1、每一个server发出一个投票给集群中其他的节点
2、收到各个服务器的投票后，判断该投票有效性，比如是否是本轮投票，是否是looking状态
3、处理投票，Pk别人的投票和自己的投票（取大原则）
4、统计是否超过半数的接收相同的选票
5、确认leader,改变服务器状态
6、添加新server，leader已经选举出来，只能以follower身份加入集群中
崩溃恢复过程
1、leader挂掉后，集群中其他follower会将状态从following状态变为looking状态，重新选举leader选举
2、同上启动过程
选举机制（3个核心原则）
1、在集群中只有超过半数以上的服务器启动，集群才能正常工作
2、在集群正常工作之前，myid小的服务器会给myid大的服务器进行投票，持续到集群正常工作，选出leader
3、选择leader之后，之前的服务器状态由looking 改变为following，以后的服务器都是following
应用场景
配置中心
在平常的业务开发过程中，通常需要将系统的一些通用的全局配置信息统一集中存储，让集群中的所有的机器共享配置信息，系统在启动时会首先从配置中心读取配置，进行初始化，传统的实现方式将配置存储在本地文件和内存中，一旦机器规模更大，配置变更频繁的情况下，本地文件和内存方式的配置维护成本较高，使用zookeeper作为分布式的配置中心就可以解决这个问题
我们将配置信息存在zk中的一个节点中，同事给该节点注册一个数据节点变更的watcher监听，一旦节点数据发生变更，所有的订阅该节点的客户端都可以获取数据变更通知
负载均衡
建立Server节点，并建立监听servers子节点的状态（用于在服务器增添时及时同步当前集群中服务器列表）。在每个服务器启动时，在server节点下建立具体服务器地址的子节点，并在对应的子节点下存入服务器的相关信息。这样我们在zk服务器上可以获取当前集群中的服务器列表以及相关的信息，可以自定义一个负载均衡算法，在每个请求过来时从zk服务器中获取当前解群服务器列表，根据算法选出一个服务器来处理请求
命名服务
DNS服务
集群管理
分布式锁
zk通过创建临时序列节点实现分布式锁，适用于顺序执行的程序。大体思路就是创建临时序列节点，找出最小的序列节点，获取分布式锁，程序执行完成之后此序列节点消失，通过watch来监控节点的变化，从剩下的节点到最小的序列节点，获取分布式锁，执行相应处理
图示
分布式队列
0 条评论
下一页
