Zookeeper系列介绍(持续更新)
ZooKeeper是一种为分布式应用提供高性能、高可用,且具有严格顺序访问控制能力的分布式协调服务。它主要应用在数据的发布/订阅、命名服务、服务注册、分布式锁、Leader选举、分布式队列、分布式ID生成等场景。这些场景下的使用方式该系列后续会详细介绍,本文主要介绍ZooKeeper基础概念。
Zookeeper目标
高性能:Zookeeper将全部数据存储在内存中,以此实现高吞吐和低延迟,适合应用于读较多的场景;
高可用:Zookeeper通常以集群模式部署,集群中服务器之间相互通信,只要一半以上的服务器能正常工作,那么集群就能正常对外提供服务,官网上集群示意图如下;
- 顺序访问:对于客户端的每个更新请求,Zookeeper都会分配一个全局唯一的递增编号zxid(ZooKeeper Transaction Id),这个编号反应了所有事务操作的先后顺序,应用程序可以使用 ZooKeeper这个特性来实现更高层次的同步原语;
Zookeeper特性
顺序一致性:从同一客户端发起的事务请求,最终会严格按照顺序进入Zookeeper服务中;
原子性:所有请求的处理结果在整个集群中所有机器上的应用情况是一致的,换句话说,要么整个集群中所有服务器都成功处理了某个请求,要么都没处理,绝不会出现只有一部分处理成功的情况;
单一性:无论客户端连到哪一个 ZooKeeper 服务器上,客户端获得的数据状态都是一致的,因为集群中服务器之间都会数据同步,保证一致性;
可靠性:每次更新请求被响应,更新的结果就会被持久化,直到被下一次更新结果覆盖;
实时性:当客户端请求被Zookeeper服务器处理后,Zookeeper仅保证客户端在一段时间内一定能获取最新的服务器数据状态,即Zookeeper保证数据状态的最终一致性,不一定保证数据的强一致性;
Zookeeper集群中的角色
Leader:领导者角色。集群通过选举过程从所有服务器中选举其中一台作为Leader,Leader为客户端提供读和写服务,它是整个集群工作机制的核心。主要承担的任务为:
事务请求的唯一调度者和处理者,以此保证集群事务处理的顺序性;
集群内部各服务器的调度者;
Follower:追随者角色。主要承担的任务为:
参与Leader选举投票;
处理客户端非事务请求【读请求】;
转发事务请求【创建、更新、删除节点等请求】给Leader服务器;
参与事务请求的Proposal提议;
Observer:观察者角色。工作原理和Follower基本一致,唯一区别是Observer不参与任何形式的投票;
Session
- Session(会话)是ZooKeeper中的会话实体,代表了一个客户端会话,其包含4个属性。
Session属性 | 解释 |
---|---|
SESSIONID | 唯一标识一个会话,每个客户端创建会话时,服务器都会为其分配一个全局唯一的SessionID |
TimeOut | 会话超时时间,在客户端创建TCP连接时指定 |
TickTime | Zookeeper自定义的时间单位,超时时间一般为2*TickTime~~20*TickTime |
IsClosing | 客户端重新成功连接服务器后,客户端当前状态 |
- Zookeeper客户端启动时会与服务器建立一个TCP长连接。从连接指令发出后,客户端Session的生命周期就开始了,在整个生命周期内会切换不同的会话状态。
Session状态 | 解释 |
---|---|
CONNECTING | 客户端开始创建Zookeeper对象时,客户端当前状态 |
CONNECTED | 客户端成功连接服务器后,客户端当前状态 |
RECONNECTING | 由于网络抖动等原因导致客户端与服务器闪断,客户端会尝试重连,客户端当前状态 |
RECONNECTED | 客户端重新成功连接服务器后,客户端当前状态 |
CLOSE | 当会话过期时,客户端当前状态 |
- 通过该TCP连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向服务器发送请求并接受响应,还能够接收来自服务器的 watch 事件通知,便于实时响应某些操作。
Zookeeper客户端操作
操作 | 解释 |
---|---|
help | 列出客户端可执行的命令 |
addauth scheme auth | 用于身份认证 |
history | 用于列出最近的命令历史,可以和redo配合使用 |
redo cmdno | 再次执行某个命令,cmdno表示命令的id,该id一般通过history查找 |
printwatches on|off | 是否关闭客户端监视状态,值为on或off |
connect host:port | 客户端连接Zookeeper |
quit | 退出客户端 |