「ReplicatedMerge原理解析」数据结构

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金。

作为 复制表系列 的基础表引擎，涵盖了数据副本最为核心的逻辑。

数据结构

在复制的核心逻辑中，大量运用了 zk 的能力，以实现多副本实例间的协同。

在执行：

• insert data
• merge partition
• MUTATION

以上操作都会涉及与 zk 的通信交互。但是在通信过程中，并不会涉及表数据的传输，而且查询数据时也不会访问 zk，所以不必担心 zk 的负载压力 (并不会像 kafka 早期的写压力)。

因为 Zookeeper 在 ReplicatedMerge 的副本协同中很重要，先从它的数据结构开始。

Zookeeper Node

ReplicatedMerge 的副本协同是通过 Zookeeper 事件监听实现的。

所以在表创建的时候，会以 zk_path 为跟卢金，在 Zookeeper 中为这张表创建一组监听节点。按照作用的不同，监听节点大致分为：

1. meta data

   1. /metadata → 保存元数据信息：包括主键，分区键等
   2. /columns → 保存列字段信息，包括列名称和数据类型
   3. /replicas → 保存副本名称，对于设置参数中的 replica_name

2. 判断标识

   1. /leader_election → 用于主副本的选举工作，会主导 MERGE/MUTATION 操作(ALTER DELETE/ALTER UPDATE)。这些操作在主副本完成之后再借助 Zookeeper 讲消息分发到其他副本中
   2. /blocks → 记录 Block 数据块的 HASH 消息摘要，以及对应的 partition_id。通过 HASH 摘要判断 Block 数据块 是否重复；通过 partition_id 能够找到需要同步的数据分区
   3. /block_numbers → 按照分区写入的顺序，以及相同的顺序记录 partition_id。各个副本在本地进行 MERGE 时，会依照形同的 block_numbers 顺序进行
   4. /quorum → 记录 quorum 的数量，当至少有 quorum 数量的副本写入成功后，整个写操作才算成功。quorum 数量由 insert_quorum 参数控制，默认为 0

3. 操作日志

   1. /log → 常规操作日志(INSERT, MERGE, DROP PARTITION)，是整个工作机制中最为重要的一环，保存副本需要执行的任务指令。其实它是一个持久化顺序型节点，副本节点会监听此node，当有新的指令加入是，会把信执行的指令加入副本各自的任务队列，并执行。
   2. /mutations → MUTATION 操作日志节点，作用和 /log 类似。针对的主要是：ALTER DELETE 和 ALTER UPDETE 时，操作指令会被添加到这个节点
   3. /replicas/{replica_name}/* → 每个副本节点下的一组监听节点，用于指导副本在本地执行具体的任务指令。比如任务队列节点，用于执行具体的操作任务

Entry Node

ReplicatedMerge 在 Zookeeper 中有两组很重要的通信塔：/log + /mutations，是分发操作指令的通道。而指令的方式，则是为这些父节点添加子节点。所有的副本节点，都会监听父节点的变化，当有子节点被添加时，会被实时感知。