Zookeeper

作用：

分布式协调服务（监听hadoop是否宕机，宕机就使用另一个集群的hadoop）

在数仓领域的场景，协调hadoop服务实现高可用

每个zk服务里面存储的是状态信息

Zookeeper特性：

• 全局数据一致：集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；（每个zk服务之间数据是同步的，相同的）
• 可靠性：如果消息被其中一台服务器接收，那么将被所有的服务器接收；（每个zk服务里存储的状态信息是一样的）
• 顺序性：在hadoop接受到请求以后，会通过一个或多个客户端连接zk然后产生状态信息，在多个客户端同时连接zk的时候，产生的状态信息会有顺序，在同步的时候，此顺序不变
• 数据更新原子性：一次数据更新要么全部成功（半数以上节点成功），要么全部失败，不存在中间状态；
• 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息；（客户端可以实时的接受到反馈信息）

Zookeeper角色：

zookeeper机器节点—多个zookeeper服务之间的角色划分：

• leader–领导者角色（负责管理维护多个zookeeper服务）

  通过内部算法进行选举，选出leader服务算法中会采用过半机制

  一旦选举出leader服务后，所有事务操作（保存、更新、删除）请求都需要交给leader处理

• follower–跟随者角色（处理获取数据请求，参与选举过程）

  定时将当前状态告知给leader（心跳机制）

• observer–观察者角色（处理查询请求，不参与选举过程）

zookeeper数据节点—zookeeper存储数据时的数据模型：

• 永久节点：保存的数据会一直存在
• 顺序永久节点：创建同一个节点时，会创建为顺序节点，在节点名称之前加序号
• 临时节点：在客户端连接过程中数据会存在，一旦客户端断开连接则数据自动删除
• 顺序临时节点

Zookeeper处理请求的过程：

• 处理事务操作（保存、更新、删除）请求：

  • leader接收到请求：

    ①leader询问每台follower是否同意操作

    ②每台follower响应并回复leader（回复则同意，不回复则不同意）

    ③leader接收到follower的回复信息采用过半机制决定是否进行事务操作

    ④leader通知follower执行事务操作

  • follower接收到请求：

    ①follower先把请求发送给leader

    ②与leader接收到请求后的过程一样

  • observer接收到请求：

    ①observer先把请求发送给leader

    ②与leader接收到请求后的过程一样

• 处理非事务操作（查询）请求：

  直接有observer（观察者）进行处理，观察者不参加选举过程

Zookeeper数据保存形式：

目录树状结构

每个存储节点（znode）里面存储着：保存的数据和子节点信息

zk数据是保存在内存上的，会有持久化机制，将数据定时保存在磁盘上

创建节点：

​ create /a 123

​ create /a/b 122

创建顺序节点：

​ create -s /a 111

无论是临时节点还是永久节点都不能重复创建，只有创建顺序节点

读取顺序节点时，需要加上序号才能读取

Zookeeper Watcher(监听机制)：

原理：

zookeeper中引入了Watcher机制来实现分布式的通知功能

zookeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能

触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等

过程：

• 客户端向服务端注册Watcher
• 服务端事件发生触发Watcher
• 客户端回调Watcher得到触发事件情况

特点：

• 一次性触发
• 事件封装
• event异步发送
• 先注册再触发

标签：知识点,请求,Zookeeper,leader,Watcher,节点,客户端
来源： https://blog.csdn.net/ljh18885466426/article/details/121715993