亲 , Zookeeper了解一下 : 概述

在学习的过程当中,咱们总须要一个来自灵魂的拷问: 为何?node

为何会产生Zookeeper

这个问题有深度,那要从五百万年提及,在遥远的塞伯坦星球.....算法

扯远了...服务器

在遥远在单机单服务的时代 , 想要扩展服务 , 只能增长硬件配置 . 如今看来 ,有如下问题:架构

  1. 硬件贵 (有钱的老板也能接受)
  2. 扩展麻烦 (在尚未实时扩展的云服务时,加硬件就意味着宕机)
  3. 没有容错 (一旦生产异常,服务就挂了,灾难)

这时候,分布式应运而生,将业务拆分开来,好比:仓库,订单,支付等等,各管各的 , 风险拆分, 好比: 订单服务挂了,不影响仓库和支付.分布式

这是分布式的初始模式, 风险少了, 再用个Nginx作个代理,集群化.而后彷佛大概也许Mybe能够 浪里个浪了 ~~工具

当项目愈来愈大,模块愈来愈多.又来问题了.性能

一开始的服务拆分并不必定很理想, 再加后期业务迭代, 可能产生不少个模块,各模块间的调用混乱 , 一条业务线中不知道串了多少个模块.学习

下图参考下: T_T代理

当你想了解一条线的时候,内心可不止一万个那啥...server

那么急需,迫切的须要一个能够把这个东西治理一下的工具.

buling~ buling ~ zookeeper来啦

zookeeper解决了哪些问题

先来感觉下使用zookeeper后的赶脚

啊.kimoji...

概念

Zookeeper是一个高性能的分布式系统的协调服务

Zookeeper特性

  1. 最终一致性

    保证各个节点服务器数据可以最终达成一致,zk的招牌功能

  2. 顺序性

    从同一客户端发起的事务请求,都会最终被严格的按照其发送顺序被应用到zk中,这也是zk选举leader的依据之一

  3. 可靠性

    凡是服务器成功的使用一个事务,并完成了客户端的响应,那么这个事务所引发的服务端状态变动会被一直保留下去

  4. 实时性

    zk不能保证多个客户端能同时获得刚更新的数据,因此若是要最新数据,须要在读数据以前强制调用sync接口来保证数据的实时性

  5. 原子性

    数据更新要么成功要么失败

  6. 单一视图

    不管客户端连的是哪一个节点,看到的数据模型对外一致

Zookeeper中的四种角色

  1. Leader

    更新系统状态,处理事务请求,负责进行投票的发起和决议

  2. Leaner

    1. Follower

    处理客户端非事务请求,并向客户端返回结果. 将写事务请求转发给Leader,同步Leadker的状态. 选举过程当中参与投票.可被选举.

    1. Observer

    接收客户端读请求,将客户端写请求转发给Leader,不参与投票过程,只同步Leader状态.目的是为了扩展系统,提升读取速度.

  3. Client

    请求发起方

Zookeeper的写入流程

数据写入最终一致性ZAB算法 .

Leader负责处理写事务请求,Follower负责向Leader转发写请求,响应Leader提出的提议.

Zookeeper选举机制

先了解几个关键字:

状态

  • looking : 寻找Leader状态,处于该状态须要进入选举过程.或正在进行选举.
  • Leading : Leader的状态,表示当前服务的角色为Leader
  • Following : 从节点 , Leader已经选出,当前为从节点
  • Observer : 观察者状态

事务ID

  • zxid : 64位数字,Leader分配,全局惟一且递增.值越大,表示操做越新.

流程

  1. 每一个节点发出一个投票,内容是(myid,zxid)
  2. 接收来自各个节点的投票,
  3. 进行投票处理和统计
    1. zxid对比,选取较大的
    2. zxid同样的,选取myid较大的
    3. 当有一半以上的服务器选出同一个节点.选举结束.
  4. 被选举的Leader节点更新状态

Zookeeper的数据模型:znode

znode是zk特有的数据模型,是zk中数据最小单元,znode上能保存数据,经过挂载子节点造成一个树状的层次结构。根由/斜杠开始。

节点类型

  • 持久节点
  • 临时节点
  • 顺序节点
  • 不一样节点类型的组合。

Zookeeper版本

  1. 当前数据节点的版本号
  2. 当前数据子节点版本号
  3. acl权限变动版本号

主要用来经过版本号来实现分布式锁的一些控制

Zookeeper : znode watch机制

znode watch机制也是zk的核心功能之一,是配置管理功能的基石。client端经过注册watch对象后,只要相应的znode触发更改,watch管理器就会向客户端发起回调,可借此机制实现配置管理的分布式更新和同步队列等场景。

参考

[1]洛神独舞:Zookeeper架构原理和使用场景总结

相关文章
相关标签/搜索