zookeeper简介

目录

zookeeper简介

  • 概念：理解为分布式文件系统。
  • 功能：为程序提供协调服务。

工作机制

基于观察者模式设计的分布式服务管理框架。
负责存储喝管理数据。接受观察者的注册。zk负责通知

优势-应用场景

  • 统一命名服务
    • 分布式环境下,需要对应用服务器进行统一命名,便于识别.
  • 统一配置管理
    • 配置文件同步
  • 统一集群管理
    • 根据节点实时状态做出调整
    • 实时监控节点变化
  • 服务器动态上下线
  • 软负载均衡
    • 如:简单实现,记录访问数量,每次路由至最少访问的

数据结构

zk的数据结构类似unix文件系统.每个节点为znode.

每个node默认存储1m的数据

zk分布式的特点

  1. 1个leader，多follower
  2. 半数以上存活，zk正常服务
  3. 全局数据一直，每个server都保存一份相同的数据。
  4. 更新请求顺序志新,来自同一个client更新请求按照顺序执行.
  5. 数据更新原子性
  6. 实时性,同步速度快

配置参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# 心跳
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
# 启动时,最大leader-follower延时时间,10心跳帧, 20s
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
# 启动后,最大leader-follower延时时间,5心跳帧 5*2000 = 10s
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
dataDir=/var/zookeeper/data
# the port at which the clients will connect
clientPort=2181
# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1

## Metrics Providers
#
# https://prometheus.io Metrics Exporter
#metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
#metricsProvider.httpPort=7000
#metricsProvider.exportJvmInfo=true

zk内部原理

选举机制

  • 半数机制: 半数以上机器存货,zk集群可用,集群最好为奇数
  • 配置文件中没有leader,follower,但是会内部选举出一个.

最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，相当于Raft算法选主时候的term，标识当前leader周期，每次选举一个新的Leader服务器后，会生成一个新的epoch

选举阶段

ZXID-本地最新事物编号,epoch和计数两部分,epoch为选举周期,每次选举出master后会生成新的epoch.

所有节点处于Looking状态，各自依次发起投票，投票包含自己的服务器ID和最新事务ID（ZXID）。

如果发现别人的ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的ZXID所属节点。
每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

发现阶段

  • 为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。
  • Leader接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。
  • 各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。

同步阶段

Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。

节点类型

持久

client和server断开,不删除数据

  • 持久化目录节点
  • 持久化顺序编号目录节点
    • zk给该节点进行顺序编号(记录事件顺序)

临时

client和server断开,删除数据

  • 临时目录节点
  • 临时顺序编号目录节点
    • 产生节点编号递增

场景如服务器上下线

znode结构

  • data 存储数据,默认不超过1m
  • acl 记录访问权限,哪些人或者ip可访问此节点
  • child 子节点
  • stat 元数据
    • czxid- 引起这个 znode 创建的 zxid，创建节点的事务的 * zxid
    • ctime - znode 被创建的毫秒数
    • mzxid - znode 最后更新的 zxid
    • mtime - znode 最后修改的毫秒数
    • pZxid-znode 最后更新的子节点 zxid
    • cversion - znode 子节点变化号，znode 子节点修改次数 * 7)dataversion - znode 数据变化号
    • aclVersion - znode 访问控制列表的变化号
    • ephemeralOwner- 如果是临时节点，这个是znode拥有者的 * session id。如果不是临时节点则是 0
    • dataLength- znode 的数据长度
    • numChildren - znode 子节点数量

监听器原理

步骤 客户端 服务端
1 main线程
2 创建zk客户端,启动2个线程,进行网络链接,同时进行监听
4 zkserver将监听事件注册监听列表
5 监听数据或路径(子节点)有变化,通知给listener
6 listener线程内部调用onProcess

写数据流程

  1. 客户端提交数据给任意follower
  2. follower把写入数据请求转发给leader
  3. leader采用二阶段提交方式,发送propose广播给follower
  4. follower接到propose消息,写入日志成功,返回ack给leader
  5. leader接到半数以上ack消息,返回成功给客户端,并且广播commit请求给follower
  6. 接收请求得follower将成功消息返回client

常用-简单命令

1
2
3
4
5
6
7
8
9
10
# 链接
zkcli -server host:port

# watch指是否监听
get path 

list
get
delete...