思维导图:
引言
本文对Zookeeper服务器的内部原理进行了简单介绍,主要分为以下三个方面:
- 服务器的分类及作用
- 服务器的会话管理
- 服务器的本地存储
一.服务器分类及工作流程
在Zookeeper服务系统中,按照独立模式与仲裁模式的区别及仲裁模式中角色的区别可以将服务器分为 独立服务器,群首服务器,追随者服务器以及观察者服务器。
1.1 独立服务器
独立服务器即是运行独立模式的Zookeeper系统时那唯一的一台服务器。其工作流程如下图:
- PrepRequestProcessor :负责将客户端请求生成为一个事务对象
- SyncRequestProcessor : 负责将事务的数据按顺序追加到事务日志中,并生成快照数据
- FinalRequestProcessor : 若是只读请求则返回相关数据,否则,按照事务对数据树进行修改
1.2 群首服务器
群首服务器是仲裁模式下服务器的一种,他主要负责对写操作进行数据树的同步处理,工作流程如下图:
- PreRequestProcessor :负责将客户端请求生成为一个事务对象
- ProposalRequestProcessor :负责利用事务对象生成一个提议对象,然后此提议被发送给追随者服务器。
- CommitRequestProcessor :接收追随者服务器对此提议的确认结果,当数量足够时,进行下一步
- ToBeAppliedRequestProcessor :删除提议列表中已准备好执行的提议
- FinalRequestProcessor :对提议所对应的的事务进行执行操作,或者返回读操作的对应信息
当然,上图中还有额外的处理流程
- SyncRequestProcessor :将事务追加的事务日志中
- AckRequestProcessor : 仅仅做一个肯定确认
1.3 追随者服务器
追随者服务器也是仲裁模式服务器的一种,主要功能是接收客户端的请求并做处理,其流程如下图:
- FollowerRequestProcessor:负责接收客户端的请求,如果是写操作,则转发请求到群首服务器
- SyncRequestProcessor :接收群首服务器发送的提议确认请求
- SendRequestProcessor :向群首服务器发送确认消息
- CommitRequestProcessor :接收群首服务器的确认提交事务的信息
- FinalRequestProcessor :对事务进行处理或者直接返回读操作的信息
1.4 群首选举
仲裁模式下,需要存在群首服务器,所以,就必须进行群首选举以确定唯一一个群首服务器。群首选举算法的原理如下:
- 服务器启动后状态被设置为LOOKING,并向此集群中所有服务器发送选举信息(sid,zxid),sid表示此服务器的id,zxid表示最近执行的事务的zxid信息。举例:(1,5)
- 服务器接收其他服务器传递的投票信息,若其他服务器的投票信息的zxid较大或者在zxid相等时,其sid较大,则将自己的投票信息修改为较大的投票信息,再次发送投票信息。否则,保留当前的投票信息。
- 最后,当服务器接收到的投票信息都一样时,表示群首服务器已被选举。群首更新状态为LEADING,其余为FOLOWING
流程如下图:
二.会话
2.1请求处理
请求处理的流程在仲裁模式下服务器的工作流程已经描述过了。
在接收到一个写请求操作后,追随者将请求转发给群首,群首探索性的执行该请求,并将执行结果以事务的方式对状态更新进行广播。追随者接收广播并进行确认。群首接收到足够数量的确认后,群首通知追随者进行提交操作。流程如下图:
2.2 监视点
Zookeeper服务器端有一个监视点管理器,并将之保存在内存中。当会话断开连接时,此会话的所有监视点就会被清除。重连后,监视点数据则会被再次同步到客户端。
2.3 会话状态
独立服务器或者群首服务器会接收会话的心跳信息。心跳信息可以是新的请求或者显示的ping消息。
2.4过期队列
服务器会维护一个叫做过期队列的数据结构。使用bucket来维护会话,其中,每一个bucket对应一个某时间范围内过期的会话。
三.本地存储
3.1 日志
服务器会通过事务日志持久化事务。事务的提交可以一次一个事务,也可以使用组提交,即在一次磁盘写入时追加多个事务。补白则是指在文件中预分配磁盘存储块。
3.2 快照
快照是对Zookeeper数据树的一次拷贝。服务器经常以序列化整个数据树的方式来提取快照。如果在快照期间数据树被修改,Zookeeper会通过记录快照开始时最后一个被提交的事务的时间戳来保证快照的正确性。