Zookeeper

Zookeeper

概念：

集群

三种角色

Leader

负责处理集群的写操作，并发起投票，只有超过半数的节点同意后 才会提交写请求

follower

处理读请求，响应结果。转发写请求到Leader，在选举leader过程中参与投票

observer

没有投票权的follower。主要书协助follower处理读请求。在读请求负载很高的时候才会处理

两种模式

恢复模式

广播模式

一旦leader已经和多数的follower进行了状态同步后，进入广播模式。进入广播模式后，如果有新加入的机器，会自动从leader中同步数据。leader在接收客户端请求后，会生成事务提案广播给其他的机器，有超过半数以上的follower同意该提议后，再提交事务

leader选举算法

启动过程

1、每一个server发出一个投票给集群中其他的节点

2、收到各个服务器的投票后，判断该投票有效性，比如是否是本轮投票，是否是looking状态

3、处理投票，Pk别人的投票和自己的投票（取大原则）

4、统计是否超过半数的接收相同的选票

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来监控节点的变化，从剩下的节点到最小的序列节点，获取分布式锁，执行相应处理

图示

分布式队列