分布式框架zookeeper

zooKeeper是什么，在哪些框架中使用？

是一个为用户的分布式应用程序提供协调的服务

是为别的分布式程序服务的

本身也是一个分布式程序(只要半数以上节点存储，就能正常提供服务)

目标是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户

Hadoop生态系统中哪些框架使用到了ZooKeeper

HDFS HA

HBase

Kafka

Spark

……

HDFS HA是有单点故障的，在生产上面就有一个HA的机制有一个主的和备用的namenode，主的namenode发生故障时，把备用的namenode切换成主的并对外提供服务（透明的，用户不感知的）

自动进行切换就需要zookeeper

HBase中作为Master的选举机制

Kafka需要和zookeeper进行通讯，然后进行一些消息的生产和消费的

掌握ZooKeeper的架构ZK的架构

1）一个ZK集群中由一组Server节点构成

2）这一组Server节点中存在一个角色为Leader的节点，剩下的其他的节点都是Follower

3）当客户端Client连接到ZK集群时，并且执行读写请求，这些请求会被发送到Leader节点上

4）然后Leader上数据变更会同步到集群的其他的Follower节点

5）Leader节点接收到数据变更请求之后，首先将变更写入到本地磁盘（为了以后容错、恢复之用），

当所有的写请求持久化到磁盘之后，才会将变更应用到内存中

6）当当前的Leader发生故障无法提供服务之后，故障/失败容错是快速响应的，会从Follower中选择

一个做为Leader(选择)，新的Leader继续做为分布式协调服务的中心，处理所有Client发起的请求。

zookeeper架构图

核心主键（Server，Leader，Follower，Client）

Server：数目一般选择为奇数（3，5，7）

Leader选举算法是采用了Paxos协议：当多数server写成功，则任务数据写成功

多数server：只要集群中有过半的机器是正常工作的，那么整个集群对外就是可用的！！

2 ZK: 死了1个，还能对外提供服务吗？因为1没有过半，所以2 ZK的死亡容忍度就是0

3 ZK: 死了1个，剩下2个，已经过半了，所以3 ZK的死亡容忍度就是1

4 ZK: 死了1个，剩下3个，已经过半了，所以4 ZK的死亡容忍度就是1

死了2个，剩下2个，没过半了，所以4 ZK的死亡容忍度就是1

....

2 => 0

3 => 1

4 => 1

5 => 2

6 => 2

2n和2n-1的死亡容忍度是一样的，都是n-1

问题：何必增加那么一个不必要的ZK呢？？？？？？

结论：ZK中的Server个数就是采用奇数个比较合适：3、5、7

了解ZooKeeper的数据结构及应用场景

层次化的目录结构

每个节点在ZK中叫做znode

znode可以包含数据和子节点(EPHEMERAL类型的节点不能有子节点)

znode中的数据可以有多个版本，可以通过版本查询数据

ZK的数据模型

1）层次化的目录结构，命名是有规范

2）每个节点叫做znode，znode是有唯一的标识的

3）znode的数据是带有版本，比如说某个znode可以存放多个数据版本，在使用时可以直接根据版本号获取数据

4）节点数据必须是一次性完成完整的读写

Zonde由路径标注，ZooKeeper中被表示成有反斜杠分割的Unicode字符串，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由反斜杠来字符开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。ZooKeeper的数据结构, 与普通的文件系统极为类似. 见下图：

图中的每个节点称为一个znode. 每个znode由3部分组成:

1.stat：此为状态信息, 描述该znode的版本, 权限等信息.

2.data：与该znode关联的数据.

3.children：该znode下的子节点.

Znode的两种类型：

1）短暂的(ephemeral)

客户端会话结束，那么zk就会将该类型的node删除，该类型的node是不可以有子节点

2）持久的(persistent)

不依赖于客户端会话，只有当客户端明确的使用命令或者是API的方式要删除该节点时才会被删除

zokeeper应用场景

配置管理

在分布式集群中，各个节点的配置文件同步文件。对集群中的一台机器的配置信息修改之后，希望能够快速同步到其他各个节点上，这可以交由ZooKeeper来实现

将配置文件信息写入到ZooKeeper的一个znode上，各个节点监听这个znode即可

集群管理

在分布式集群中，各个节点的实时状态统计

将节点信息写入到ZooKeeper的一个znode上，监听这个znode可以获取它的实时状态变化

Hbase中Master状态监控和选举

总结：

zk核心：仲裁机制，目录式的数据结构

zk架构：

服务端（奇数个，3，5，7。。。）leader(1) follower(n)

数据的读写：

客户端

zk数据结构：

目录树：持久 瞬时