ClickHouse Keeper 源码解析
简介:ClickHouse 社区在21.8版本中引入了 ClickHouse Keeper。ClickHouse Keeper 是完全兼容 Zookeeper 协议的分布式协调服务。本文对开源版本 ClickHouse v21.8.10.19-lts 源码进行了解析。
作者简介:范振(花名辰繁),阿里云开源大数据-OLAP 方向负责人。
内容框架
- 背景
- 架构图
- 核心流程图梳理
- 内部代码流程梳理
- Nuraft 关键配置排坑
- 结论
- 关于我们
- Reference
背景
注:以下代码分析版本为开源版本 ClickHouse v21.8.10.19-lts。类图、顺序图未严格按照 UML 规范;为方便表意,函数名、函数参数等未严格按照原版代码。
HouseKeeper Vs Zookeeper
- Zookeeper java 开发,有 JVM 痛点,执行效率不如 C++;Znode 数量太多容易出现性能问题,Full GC 比较多。
- Zookeeper 运维复杂,需要独立部署组件,之前出问题比较多。HouseKeeper 部署形态比较多,可以 standalone 模式和集成模式。
- Zookeeper ZXID overflow 问题,HouseKeeper 没有该问题。
- HouseKeeper 读写性能均有提升,支持读写线性一致性,关于一致性的级别参见Consistency Models in Distributed System - Random Notes。
- HouseKeeper 代码与 CK 统一,自主闭环可控。未来可扩展能力强,可以基于此做 MetaServer 的设计开发。主流的的 MetaServer 基本都是 Raft+rocksDB 的组合,可以借助该 codebase 进行开发。
Zookeeper Client
- Zookeeper Client 完全不需要修改,HouseKeeper 完全适配 Zookeeper 的协议。
- Zookeeper Client 由 CK 自己开发,放弃使用 libZookeeper(是一个bad smell代码库),CK 自己从 TCP 层进行封装遵循 Zookeeper Protocol。
架构图
- 3种部署模式,推荐第一种 standalone 方式,可以选择小机型 SSD 磁盘,最大程度发挥 Keeper 的性能。
核心流程图梳理
类图关系
- 入口 main 函数,主要做2件事:
- 初始化 Poco::Net::TCPServer,定义处理请求的 KeeperTCPHandler。
- 实例化 keeper_storage_dispatcher,并且调用 KeeperStorageDispatcher->initialize()。该函数主要作用是以下几个:
- 实例化类图中的几个 Threads,以及相关的 ThreadSafeQueue,保证不同线程间同步数据。
- 实例化 KeeperServer 对象,该对象是核心数据结构,是整个 Raft 的最重要部分。KeeperServer 主要由 state_machine,state_manager,raft_instance,log_store(间接)组合成,他们分别继承了 nuraft 库中的父类。一般来说,所有 raft based 应用均应该实现这几个类。
- 调用 KeeperServer::startup(),主要是初始化 state_machine,state_manager。启动过程中会调用 state_machine->init(), state_manager->loadLogStore(...),分别进行 snapshot 和 log 的加载。从最新的 raft snapshot 中恢复到最新提交的 latest_log_index,并形成内存数据结构(最关键是 Container 数据结构,即KeeperStorage::SnapshotableHashTable),然后再继续加载 raft log 文件中的每一条记录至 logs (即数据结构 std::unordered_map),这两个粗体的唯二的数据结构,是整个 HouseKeeper 的核心,也是内存大户,后边会提及。
- KeeperTCPHandler 主循环是读取 socket 请求,将请求 dispatcher->putRequest(req) 交给 requests_queue,然后通过 responses.tryPop(res) 从中读到 response,最终写 socket 将 response 返回给客户端。主要经历以下几个步骤:
- 确认整个集群是否有 leader,如果有,sendHandshake。注意:HouseKeeper利用了 naraft 的 auto_forwarding 选项,所以如果接受请求的是非 leader,会承担 proxy 的作用,将请求 forward 到 leader,读写请求都会经过 proxy。
- 获得请求的 session_id。新来的 connection 获取 session_id 的过程是服务端 keeper_dispatcher->internal_session_id_counter 自增的过程。
- keeper_dispatcher->registerSession(session_id,response_callback),将对应的 session_id 和回调函数绑定。
- 将请求 keeper_dispatcher->putRequest(req) 交给 requests_queue。
- 通过循环 responses.tryPop(res) 从中读到 response,最终写 socket 将 response 返回给客户端。
处理请求的线程模型
- 从 TCPHandler 线程开始经历顺序图中的不同线程调用,完成全链路的请求处理。
- 读请求直接由 requests_thread 调用 state_machine->processReadRequest 处理,在该函数中,调用 storage->processRequest(...) 接口。
- 写请求通过 raft_instance->append_entries(entries) 这个 nuraft 库的 User API 进行 log 写入。达成 consensus 之后,通过 nuraft 库内部线程调用 commit 接口,执行 storage->processRequest(...) 接口。
- Nuraft 库的 normal log replication 处理流程如下图:
- Nuraft 库内部维护两个核心线程(或线程池),分别是:
- raft_server::append_entries_in_bg,leader 角色负责查看 log_store 中是否有新的 entries,对 follower 进行 replication。
- raft_server::commit_in_bg,所有角色(role,follower)查看自己的状态机 sm_commit_index 是否落后于 leader 的 leader_commit_index,如果是,则 apply_entries 到状态机中。
内部代码流程梳理
总体上nuraft实现了一个编程框架,需要对类图中标红的几个class进行实现。
LogStore与Snapshot
- LogStore 负责持久化 logs,继承自 nuraft::log_store,这一系列接口中比较重要的是:
- 写:包括顺序写 KeeperLogStore::append(entry),覆盖写(截断写) KeeperLogStore::write_at(index, entry),批量写 KeeperLogStore::apply_pack(index, pack)等。
- 读:last_entry(),entry_at(index) 等。
- 合并后清理:KeeperLogStore::compact(last_log_index),主要会在 snapshot 之后进行调用。当 KeeperStateMachine::create_snapshot(last_log_idx) 调用时,当所有的 snapshot 将数据序列化到磁盘后,会调用 log_store_->compact(compact_upto),其中 compact_upto = new_snp->get_last_log_idx() - params->reserved_log_items_。这是一个小坑, compact 的 compact_upto index 不是已经做过 snapshot 的最新 index,需要有一部分的保留,对应的配置是 reserved_log_items。
- ChangeLog 是 LogStore 的 pimpl,提供了所有的 LogStore/nuraft::log_store 的接口。ChangeLog 主要是由 current_wirter(log file writer)和 logs(内存std::unordered_map数据结构)组成。
- 每插入一条 log,会将 log 序列化到 file buffer 中,并且插入到内存 logs 中。所以可以确定,在未做 snapshot 之前,logs 占用内存会一直增加。
- 当做完 snaphost 之后,会把已经序列化磁盘中的 compact_upto 的 index 从内存 logs 中 erase 掉。所以,我们需要 trade off 两个配置项 snapshot_distance 和 reserved_log_items。目前两个配置项缺省值都是10w条,容易大量占用内存,推荐值是:
- 10000
- 5000
- KeeperSnapshotManager 提供了一系列 ser/deser 的接口:
- KeeperStorageSnapshot 主要是提供了 KeeperStorage 和 file buffer 互相 ser/deser 的操作。
- 初始化时,直接通过 Snapshot 文件进行 deser 操作,恢复到文件指示的 index(如 snapshot_200000.bin,指示的 index 为200000)所对应的 KeeperStorage 数据结构。
- KeeperStateMachine::create_snapshot 时,根据提供的 snapshot 元数据(index,term等),执行 ser 操作,将 KeeperStorage 数据结构序列化到磁盘。
- Nuraft 库中提供的 snapshot transmission:当新加入的 follower 节点或者 follower 节点的日志落后很多(已经落后于最新一次 log compaction upto_index),leader 会主动发起 InstallSnapshot 流程,如下图:
- Nuraft 库针对 InstallSnapshot 流程提供了几个接口。KeeperStateMachine 对此进行了简单的实现:
- read_logical_snp_obj(...),leader 直接将内存中最新的快照 latest_snapshot_buf 发送。
- save_logical_snp_obj(...),follower 接收并序列化落盘,更新自身的 latest_snapshot_buf。
- apply_snapshot(...),将最新的快照 latest_snapshot_buf,生成最新版本的 storage。
KeeperStorage
这个类用来模拟与 Zookeeper 对等的功能。
- 最核心的数据结构是 Zookeeper 的 Znode 存储:
- using Container = SnapshotableHashTable,由 std::unordered_map 和 std::list 组合来实现一种无锁数据结构。key 为 Zookeeper path,value 为 Zookeeper Znode(包括存储 Znode 的 stat 元数据),Node 定义为:
struct Node{String data;uint64_t acl_id = 0; /// 0 -- no ACL by defaultbool is_sequental = false;Coordination::Stat stat{};int32_t seq_num = 0;ChildrenSet children{};};
- SnapshotableHashTable 结构中的 map 总是保存最新的数据结构,用来满足读需求。list 提供两段数据结构,保障新插入的数据不影响正在做 snapshot 的数据。实现很简单,具体见:https://github.com/ClickHouse/ClickHouse/blob/v21.8.12.29-lts/src/Coordination/SnapshotableHashTable.h
- 提供了 ephemerals,sessions_and_watchers,session_and_timeout,acl_map,watches 等数据结构,实现都很简单,就不一一介绍了。
- 所有的 Request 都实现自 KeeperStorageRequest 父类,包括下图的所有子类,每一个 Request 实现了纯虚函数,用来对 KeeperStorage 的内存数据结构进行操作。
virtual std::pair<Coordination::ZooKeeperResponsePtr, Undo> process(KeeperStorage & storage, int64_t zxid, int64_t session_id) const = 0;
Nuraft 关键配置排坑
- 阿里云 EMR ECS 机器对应的操作系统版本比较老(新版本已经解决),对于 ipv6 支持不好,server 启动不了。workaround 方法是先将 nuraft 库 hard coding 的 tcp port 改成 ipv4。
- 做5轮 zookeeper 压测,发现内存一直上涨,现象接近内存泄露。结论是:不是内存泄露,需要调整参数,使 logs 内存数据结构不占用过多内存。
- 每一轮先创建500w个 Znode,每个 Znode 数据是256,再删除500w Znode。具体过程是:利用 ZookeeperClient 的 multi 模式,每一轮发起5000次请求,每个请求 transaction 创建1000个 Znode,达到500w个 Znode 后,再发起5000次请求,每个请求删除1000个 Znode,这样保证每一轮所有的 Znode 全部删除。这样即每一轮插入10000条 logEntry。
- 过程中发现每一轮内存都会上涨,经过5轮之后内存上涨到20G以上,怀疑是内存泄露。
- 加入代码 profile 打印 showStatus 之后,发现每一轮 ChangeLog::logs 数据结构一直增长,而 KeeperStorage::Container 数据结构会随着 Znode 数量而周期变化,最终回归0。结论是:由于 snapshot_distance 默认配置是10w条,所以,一直没有发生 create_snapshot,也即没有发生 compact logs,ChangeLog::logs 内存占用会越来越多。所以建议配置为:
- 10000
- 5000
- 通过配置 auto_forwarding,可以让 leader 把请求转发给 follower,对 ZookeeperClient 是透明实现。但是这个配置 nuraft 不推荐,后续版本应该会改善该做法。
结论
- 去掉 Zookeeper 依赖会让 ClickHouse 不再依赖外部组件,无论从稳定性和性能都向前迈进了一大步,为逐渐走向云原生化提供了前提。
- 基于该 codebase,后续将会逐步衍生出基于 Raft 的 MetaServer,为支持存算分离、支持分布式 Join 的 MPP 架构等方向提供了前提。
关于我们
计算平台开源大数据团队致力于开源引擎的内核研发工作,OLAP 方向包括 ClickHouse,Starrocks,Trino(PrestoDB) 等。
原文链接
本文为阿里云原创内容,未经允许不得转载。
ClickHouse Keeper 源码解析相关推荐
- 2022-10-24 ClickHouse 源码解析-查询引擎经典理论
ClickHouse 源码解析: 综述 ClickHouse 源码解析: MergeTree Write-Path ClickHouse 源码解析: MergeTree Read-Path Click ...
- clickhouse原理解析与开发实战 pdf_重识SSM,“超高频面试点+源码解析+实战PDF”,一次性干掉全拿走...
重识SSM,"超高频面试点"+"源码解析"+"实战PDF",一次性干掉全拿走!! 01 超高频面试点知识篇 1.1 Spring超高频面试点 ...
- 谷歌BERT预训练源码解析(二):模型构建
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/weixin_39470744/arti ...
- 谷歌BERT预训练源码解析(三):训练过程
目录 前言 源码解析 主函数 自定义模型 遮蔽词预测 下一句预测 规范化数据集 前言 本部分介绍BERT训练过程,BERT模型训练过程是在自己的TPU上进行的,这部分我没做过研究所以不做深入探讨.BE ...
- 谷歌BERT预训练源码解析(一):训练数据生成
目录 预训练源码结构简介 输入输出 源码解析 参数 主函数 创建训练实例 下一句预测&实例生成 随机遮蔽 输出 结果一览 预训练源码结构简介 关于BERT,简单来说,它是一个基于Transfo ...
- Gin源码解析和例子——中间件(middleware)
在<Gin源码解析和例子--路由>一文中,我们已经初识中间件.本文将继续探讨这个技术.(转载请指明出于breaksoftware的csdn博客) Gin的中间件,本质是一个匿名回调函数.这 ...
- Colly源码解析——结合例子分析底层实现
通过<Colly源码解析--框架>分析,我们可以知道Colly执行的主要流程.本文将结合http://go-colly.org上的例子分析一些高级设置的底层实现.(转载请指明出于break ...
- libev源码解析——定时器监视器和组织形式
我们先看下定时器监视器的数据结构.(转载请指明出于breaksoftware的csdn博客) /* invoked after a specific time, repeatable (based o ...
- libev源码解析——定时器原理
本文将回答<libev源码解析--I/O模型>中抛出的两个问题.(转载请指明出于breaksoftware的csdn博客) 对于问题1:为什么backend_poll函数需要指定超时?我们 ...
最新文章
- 在机器人的眼里到底能看到什么,它们和人类的视觉系统有什么区别?
- 人脑动态功能网络连接模式能够鉴别个体并预测其认知功能
- bower解决js的依赖管理
- ORB-SLAM / ORB-SLAM2原理解读+代码解析(汇总了资料,方便大家学习)
- JDK与JRE及其在Eclipse中的使用
- linux之vim/vi快速复制多行内容的快捷键
- android 副mic测试,【收藏】Android Audio Framework CTS Verifier 测试方法
- POSIX条件变量API函数
- 认识Java异步编程
- php 构造函数 返回值,php构造函数与析构函数实例分析
- 【JAVA 第三章 流程控制语句】课后习题 判断用户输入的数是否为质数
- react 中组件隐藏显示_React组件开发中常见的陷阱及解决
- 安装ps时无法验证订阅状态_免费申请office E5开发者订阅,附无限续期+私人网盘教程...
- mysql 5.7 root密码重置(centos 7)
- omnet++ 中tictoc10-12学习笔记
- 枚举中valueOf用法
- 魔童降世-暴走的哪吒
- 金融数据分析 实验五 资产组合计算
- Java Annotation自定义注解详解
- 荣耀30pro系统_荣耀30pro和pro+的区别_荣耀30pro和pro+的区别对比详情 - 系统家园
热门文章
- 台式电脑耳机插孔在哪_一图教你学会电脑主机后面各接口正确接线
- html360度视角观赏,360度全景图是如何生成的?
- php实现第三方邮箱登录_JavaScript实现第三方登录网站原理在这呢
- 零基础学习java必须要了解的学习路线
- 小学计算机课程评价,小学信息技术课堂评价浅谈
- 【学习笔记】第一章——操作系统的中断和异常
- 我的世界java多大内存_我的世界电脑版内存多大
- python计算期望值_机器学习:计算方差时为何除以n-1
- python socketserver最大连接_大聊Python----SocketServer
- element ui 多个子组件_vue前端UI框架,一点都不圆润,盘它!