乐趣区

关于后端:ClickHouse-Keeper-源码解析

jiezi

简介：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 读写性能均有晋升，反对读写线性一致性，对于一致性的级别参见 https://xzhu0027.gitbook.io/b…。

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 default
        bool is_sequental = false;
        Coordination::Stat stat{};
        int32_t seq_num = 0;
        ChildrenSet children{};};
  • SnapshotableHashTable 构造中的 map 总是保留最新的数据结构，用来满足读需要。list 提供两段数据结构，保障新插入的数据不影响正在做 snapshot 的数据。实现很简略，具体见：https://github.com/ClickHouse…
  • 提供了 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) 等。

原文链接
本文为阿里云原创内容，未经容许不得转载。

退出移动版