聊聊分布式 SQL 数据库Doris(二)

这篇具有很好参考价值的文章主要介绍了聊聊分布式 SQL 数据库Doris(二)。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Doris中，Leader节点与非Leader节点和Observer节点之间的元数据高可用和一致性，是通过bdbje(全称:Oracle Berkeley DB Java Edition)的一致性和高可用实现的。

元数据与同步流程

元数据主要存储四类数据：

用户数据信息. 包括数据库, 表的schema, 分片信息等
各类作业信息. 如导入作业, clone作业, schemaChange作业等。
用户及权限信息.
集群及节点信息.

元数据同步图:

聊聊分布式 SQL 数据库Doris(二)

元数据流转如下：

leader写入元数据

写操作在修改leader的内存后，序列化为log，按照key-value格式写入到bdbje. 其中 key 为连续的整型数字，全局唯一、递增，作为 log id；value 即为序列化后的操作日志，由2部分组成。OperationType为操作类型，如建库操作、建表操作等。Writable Entity为序列化后的操作具体内容，通过反序列化该值，可以从镜像上回放元数据操作。
集群节点同步元数据

日志写入bdbje后，bdbje会根据策略(写多数/全写), 将日志复制到FE其他的follower节点。FE节点通过对bdbje中元数据日志的reply, 修改自身的元数据内存镜像，完成与leader节点的元数据同步。
元数据checkpoint持久化

leader 节点的日志条数达到阈值（默认 10w 条）并且满足checkpoint线程执行周期（默认六十秒）。checkpoint 会读取已有的 image 文件，和其之后的日志，重新在内存中回放出一份新的元数据镜像副本。然后将该副本写入到磁盘，形成一个新的 image。之所以是重新生成一份镜像副本，而不是将已有镜像写成 image，主要是考虑写 image 加读锁期间，会阻塞写操作。所以每次 checkpoint 会占用双倍内存空间。
image 文件生成后，leader 节点会通知其他 non-leader 节点新的 image 已生成。non-leader 主动通过 http 拉取最新的 image 文件，来更换本地的旧文件.
bdbje 中的日志，在 image 做完后，会定期删除旧的日志
删除旧的磁盘元数据镜像

总结

Leader节点修改内存元数据后，元数据日志首先写入bdbje，达到阈值后，bdbje形成一个新的DB，然后将新的DB内的日志，在旧的image上回放，生成一个新的image，然后删除bdbje中已经被集群节点全部同步的旧的元数据日志。这样周而复始。保证bdbje中的数据不会无限制得增长，也保证了image中始终保存着较新的元数据。同时，其他非leader节点，也访问bdbje，将bdbje中的新写入的元数据日志，在自己内存中的元数据上回放。

元数据层面，Doris采用Paxos协议以及Memory + Checkpoint + Journal的机制来确保元数据的高性能及高可靠。Doris的元数据存储是 memory -> bdbje -> checkpoint(image)。

为什么同时需要 bdbje 和 image 镜像呢？