Zookeeper应用场景和底层设计

一、什么是zookeeper

Zookeeper是一个开源的分布式协调服务框架，它是服务于其它集群式框架的框架。

【简言之】
有一个服务A，以集群的方式提供服务。只需要A专注于它提供的服务就可以，至于它如何以多台服务器协同完成任务的事情，交给Zookeeper来协调。

【底层设计逻辑】
1）基于观察者设计模式
2）等价于文件系统+通知机制

【数据存储的方式】
zookeeper是文件系统，当然是像树一样的结构存储
1）每个节点都有唯一路径标识
2）每个节点默认只能存储1M数据

【zookeeper运行规则】
1）支持一个leader，多个follower组成的集群方式运行
2）集群中半数以上节点存活，zookeeper就能提供正常的服务
3）集群中的每个服务器上保存的数据都完全相同，具有数据一致性
4）同一个客户端的请求会按照请求的顺序执行
5）数据更新具有原子性，要么全部更新成功，要么不更新

【zookeeper中节点类型】
是否持久（-e参数）
1）持久型：客户端与服务器端断开连接后，创建节点不删除create /nodename
2）短暂型：客户端与服务器端断开连接后，创建节点自己删除create -e /nodename
是否有序列号（-s参数）
1）有create -s /nodename: /nodename0000000003 可依据序号进行全局的事务排序
2）无create /nodename: /nodename
容器节点
1）当子节点都不存在后，容器节点就会自动消失
TTL节点
1）当超过时间，自动消失

【zookeeper中节点信息】
1）存储的数据信息
2）路径信息
3）节点的元数据
4）子节点信息

二、zookeeper应用场景

1、统一命名：唯一名称标识

在这里插入图片描述

2、统一配置管理：所有节点配置信息一致、更新后快速更新到各个节点上

在这里插入图片描述

3、统一集群管理：每一个节点可以立即感知到其它节点的变化

在这里插入图片描述

4、服务器节点动态上下线

在这里插入图片描述

5、软负载均衡

在这里插入图片描述

三、zookeeper中相关的底层原理

1、选举机制

集群的机器数量是奇数还是偶数？
答：当然是奇数好，不然容易平票

怎样一种情况表示选举成功？
答：投票数最先超过半数的机器成为leader，不论先来后到

机器状态有哪些？
1）looking：选举态
2）leading：当官态，正常工作态
3）following：随从态，正常工作态

选票格式是什么样的，如何比较各个信息？
答：每一张选票上包含三个信息
1）epoch：参加过几次选举
2）zxid：最大事务ID
3）sid：服务器编号
按照顺序依次比较，谁大选谁

什么时候开始选举？
答：分两种情况
【情况1——zookeeper集群搭建过程中】
在没有选出leader之前都处于looking状态，并且新加进来一个机器就组织一次选举直到选出leader，后面新加进来的机器都是follower。
【情况2——集群运行过程中，leader“挂掉了”】
如果是某个follower认为leader挂掉了，实际上leader在正常工作。这种情况下，不会进行选举，只是要求该follower不断尝试与leader获取连接直到成功。
如果leader真的挂掉了，会在所有正常工作的follower中安装选票信息进行重新选举。

如何判断leader是否挂掉了？
答：在工作过程中，leader会发送带有ping的信息给follower，当follower一段时间内没有读取到该信息，就可以任务该leader挂掉了。