七、zookeeper集群独写数据同步原理

文章目录

• 概述
• 先行概念
• • leader工作流程涉及的代码角色
  • • PrepRequestProcessor
    • ProposalRequestProcessor
    • Commit
    • Sync
    • Ack
    • Final
    • 通知follower信号
  • follower工作流程设计的代码角色
  • • FollowerRequestProcessor
    • SendAckRequestProcessor
• 实际工作流程
• • • 客户端基于leader的读请求流程
    • 客户端基于leader的写请求
    • 客户端基于follower的读请求
    • 客户端基于follower的写请求

概述

在集群环境下客户端可能会请求不同的zookeeper完成相应的节点操作，那么集群之间zookeeper是如何实现数据同步的呢？本篇文章就会基于四种情况进行分析。

先行概念 leader工作流程涉及的代码角色 PrepRequestProcessor

负责接受客户端的请求，进行相应预处理标记操作操作

ProposalRequestProcessor

接收PrepRequestProcessor 发送过来的请求内容，具体如下流程图所示，总的来说就是当出现写操作时就得通知sync对象进行操作记录：

Commit

leader工作流程中有个事务管理对象，具体工作流程图如下所示，简明来说就是当ProposalRequestProcessor 传来的请求是写请求就进行日志记录一下，当有需要提交的事务时就进行提交，否则就继续往复之前的操作

Sync

简单来说就是出现写请求时候需要对操作进行日志记录一下

Ack

当Sync完成操作归档后，就会让ack通知leader本次归档完成。

Final

最终执行操作的工作角色

通知follower信号

REQUEST
PROPOSAL
ACK
COMMIT

follower工作流程设计的代码角色

follower工作流程大体上不变，仅仅是将PrepRequestProcessor 改为FollowerRequestProcessor 。以及ack变为SendAck

FollowerRequestProcessor

SendAckRequestProcessor

SendAckRequestProcessor 的逻辑是当sync完成操作信息归档后，通知leader当前操作记录归档完成

实际工作流程 客户端基于leader的读请求流程

具体工作流程如下流程图所示，很明显，基于leader的读请求很简单，只要预处理preRequestProcessor完成操作标记之后一路交给final完成数据查询返回即可。

客户端基于leader的写请求

写请求就比较复杂了，如下图所示，当leader收到客户端的写请求，首先prep会进行写操作标记，然后交给proposal，proposal会通知follower当前有一个写请求的信息(需要了解是，这条信息中会注明事务编号，为了严格保证提交事务的顺序，每一次的写事务分配一个唯一的递增数字，从 0 开始)，双方都进行sync操作记录后，都会发送一个ack给leader，当半数以上的zookeeper收到ack确认后，都会通知各自的commit提交事务，让final完成事务提交。

客户端基于follower的读请求

可以看出follower的读请求与leader无异，只是预处理人是followerRequestProcessor而已

客户端基于follower的写请求

如下图流程图所示，同步流程可以简述为follower收到写请求后会交给leader进行处理，leader通知所有follower写操作请求后，当半数以上zookeeper完成写操作日志创建并发送ack确认后，所有commit都会提交事务，由final完成写操作。