zookeeper知识点(二)
zookeeper集群
zookeeper是由多个server组成的集群,一个leader,一个follower。
leader为客户端服务器提供读写服务,除了leader外其他的机器只能提供读服务。
每个server保存一份数据副本,全数据一致;分布式读follower,写由leader实施更新请求转发。
由leader实施更新请求顺序进行,来自同一个client的更新请求按其发送的顺序依次执行,保持原子性,要么成功,要么失败。
zookeeper角色
leader:是整个zookeeper集群工作机制的核心。负责响应所有对Zookeeper状态变更的请求。主要工作如下:
- 事务请求的唯一调度和处理,保持集群处理事务的顺序性
- 集群内各服务器的调度者
leader的选举是zookeeper最重要的技术之一,假如有三个服务器server启动, 每个机器都视图找到一个leader,就进入了leader选举流程:
- 每个 server 发出一个投票,投票的最基本元素是(SID-服务器id,ZXID-事物id)
- 接受来自各个服务器的投票 处理投票
- 优先检查 ZXID(数据越新ZXID越大),ZXID比较大的作为leader,ZXID一样的情况下比较SID
- 统计投票 这里有个过半的概念,大于集群机器数量的一半,即大于或等于(n/2+1),我们这里的由三台,大于等于2即为达到“过半”的要求。
这里也有引申到为什么 Zookeeper 集群推荐是单数。
“过半”设计策略也适用在广播通知中,leader在收到过半的follower的ack后,即认为消息抵达了
Follower:是zookeeper集群状态的跟随者,,除了响应服务器上的读请求外,还要处理leader的提议。需要注意的是, leader和follower是构造zookeeper集群的法定人数,只有他们能参与新的leader的选举和响应leader的提议。
Observer:服务器的观察者。如果 ZooKeeper 集群的读取负载很高,或者客户端多到跨机房,可以设置一些 observer 服务器,以提高读取的吞吐量。 Observer 和 Follower 比较相似,只有一些小区别:首先 observer 不属于法定人数,即不参加选举也不响应提议,也不参与写操作的“过半写成功”策略; 其次是 observer 不需要将事务持久化到磁盘,一旦 observer 被重启,需要从 leader 重新同步整个名字空间。
会话(Session)
Session指的是zookeeper服务器与客户端的会话。在zookeeper中,一个客户端链接是只客户端和服务器之间的一个TCP长连接。 客户端启动的时候,首先会与服务器建立一个 TCP 连接,从第一次连接建立开始,客户端会话的生命周期也开始了。 通过这个连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向Zookeeper 服务器发送请求并接受响应,同时还能够通过该连接接收来自服务器的Watch事件通知。 Session 的 sessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时, 只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器,那么之前创建的会话仍然有效。在为客户端创建会话之前,服务端首先会为每个客户端都分配一个sessionID。 由于 sessionID 是 Zookeeper 会话的一个重要标识,许多与会话相关的运行机制都是基于这个 sessionID 的,因此,无论是哪台服务器为客户端分配的 sessionID,都务必保证全局唯一。
会话创建
session是zookeeper的会话实体,代表了一个客户端会话,其包含了如下四个属性:
- sessionID 会话ID,唯一标识的一个会话,每个客户端创建新的会话时,zookeeper都会为其分配一个全局唯一的sessionID
- TimeOut 会话超时时间,客户端构造zookeeper实例时,会配置sessionTimeout参数用于指定会话的超时时间,服务器会根据自己的超时时间限制最后确定会话的超时时间。
- TikTime 下次会话超时时间点,为了便于zookeeper对会话实行“分桶策略”管理,同时为了高效低耗地实现会话的超时检查和清理,zookeeper会为每个会话都标记一个下次会话超时时间点, 其值大致等于当前时间 + timeout
- isClosing。标记一个会话是否已经被关闭,当服务器检测会话已经超时失效时,会将该会话的isClosing标记为"已关闭",这样就能确保不再处理来自该会话的新请求了。
数据节点 Znode
"节点"分两类,第一类指构成集群的机器,称之机器节点;第二类是数据模型中的数据单元,我们称之数据节点--ZNode。 zookeeper将所有数据存储在内存中,树形存储,每个节点会保存自己的数据内容,还会存储一系列属性信息。
节点类型
node可以分持久节点和临时节点和顺序节点三大类。可通过组合生成如下四种类型节点:
- PERSISTENT 持久节点 创建后会一直存在于zookeeper服务器中,直到删除
- PERSISTENT_SEQUENTIAL 持久顺序节点, 相比持久节点,其新增了顺序特性,每个父节点都会为他的第一级子节点维护一份顺序,用于记录每个子节点创建的先后顺序。 在创建节点时,会自动添加一个数字后缀,作为新的节点名,改数字后缀的上限是整形的最大值
- EPEMERAL 临时节点,其生命周期和客户端会话绑定在一起,客户端失效,节点自动删除。
- EPEMERAL_SEQUENTIAL 临时顺序节点 在临时节点上添加了顺序特性。
版本--保证分布式数据的原子性操作
每个数据节点都具有三种类型的版本信息,对数据节点的任何更新操作都会引起版本号的变化。
- version– 当前数据节点数据内容的版本号
- cversion– 当前数据子节点的版本号
- aversion– 当前数据节点ACL变更版本号