5.2 协调服务依赖

5.2 协调服务依赖

本节摘要：副本之间靠协调服务对齐。ClickHouse 历史上依赖 ZooKeeper，现在官方推出了自研的 ClickHouse Keeper 作为替代。本节讲清两者角色、副本协调机制、以及部署选择。

本节导读

阅读完本节，你应当能够：

1. 说清协调服务在副本协调中的作用
2. 区分 ZooKeeper 和 ClickHouse Keeper
3. 描述 ReplicatedMergeTree 的副本同步机制
4. 做出协调服务的部署选择

一、为什么需要协调服务

单机 MergeTree 不需要协调服务。但一旦用了 ReplicatedMergeTree（带副本），副本之间要保持一致，就需要一个独立的协调服务来记录"谁写了什么、谁该同步什么"。这个协调服务就是 ZooKeeper 或 ClickHouse Keeper。

它的作用有几块：

• 记录写入日志：每个 part 的插入在协调服务里记一条，副本通过消费这条日志知道要拉取哪个 part。
• 选主与互斥：合并、mutation 等后台任务在副本间互斥执行，避免重复劳动。
• 存元数据：part 的状态、副本活跃状态等。

没有协调服务，副本之间没法对齐——你不知道对端有什么、自己缺什么。

二、ZooKeeper 与 ClickHouse Keeper

历史上 ClickHouse 用 ZooKeeper 做协调服务。ZooKeeper 是成熟的分布式协调服务，但用 Java 写、依赖 JVM、部署运维偏重。ClickHouse 团队后来用 C++ 自研了 ClickHouse Keeper，作为 ZooKeeper 的替代。

两者协议兼容（Keeper 实现了 ZooKeeper 的协议），ClickHouse 配置里可以二选一。Keeper 的优势是：和 ClickHouse 同语言栈、部署简单（一个二进制）、资源占用小、能和 ClickHouse 进程同机部署或独立部署。

新集群建议直接用 ClickHouse Keeper，少一套运维栈。生产部署通常 3 节点（容忍 1 节点故障）或 5 节点（容忍 2 节点故障）。

三、ReplicatedMergeTree 的同步机制

ReplicatedMergeTree 在 ZooKeeper/Keeper 里为每张表维护一个日志队列。写入流程大致是：

1. 写入到一个副本，该副本把 part 落盘后在协调服务里记一条"新 part 可用"。
2. 其他副本监听到这条日志，从源副本拉取这个 part。
3. 拉取完成后在本地落地，并在协调服务里更新状态。

合并也类似：一个副本发起合并，在协调服务里登记，其他副本看到后要么各自合并、要么直接拉取合并结果（避免重复计算）。

这套机制保证副本最终一致——写入先在一个副本可见，其他副本异步追上。期间有"副本延迟"（某个副本落后于源副本），这是正常的最终一致表现。

四、部署选择

协调服务的部署有两种模式：

• 独立部署：Keeper 单独跑在几台机器上，和 ClickHouse 解耦。适合大集群，资源充足。
• 混部：Keeper 和 ClickHouse 同机部署（每个 CH 节点跑一个 Keeper）。适合中小集群，省机器，但争资源。

无论哪种，生产至少 3 节点保证多数派可用。Keeper 节点数建议奇数（3 或 5）。

⚠️ 常见坑：协调服务是集群的命脉，它挂了副本就没法同步、合并也停。生产里 Keeper 要单独监控、独立资源、定期备份它的快照。很多人只盯 ClickHouse 不盯 Keeper，结果 Keeper 出问题整个集群瘫痪。

💡 关键直觉：协调服务是副本对齐的"账本"，记录谁有什么、谁缺什么。新集群用 ClickHouse Keeper，省一套运维栈，但它同样是命脉，要同等重视地监控。

重点提炼

• 协调服务作用：记录写入日志、选主互斥、存元数据，副本对齐靠它。
• ZooKeeper vs Keeper：Keeper 是 C++ 自研、协议兼容、轻量，新集群首选。
• 同步机制：写入副本记日志 → 其他副本监听拉取 part → 落地更新状态，最终一致。
• 部署：独立或混部，生产至少 3 节点奇数，Keeper 是命脉要单独监控。
• 副本延迟是最终一致的正常表现，监控它别误判为故障。

下一节讲这套机制保证什么一致性级别，以及写入语义的代价。

用 SQL 检查协调服务健康

协调服务是集群命脉，健康检查不能靠运气。ClickHouse 在 system 表里暴露了副本与协调服务的连接状态，排查"副本卡住"类问题先看这几张表：

-- 副本同步状态：延迟和会话是否过期
SELECT
    database,
    table,
    replica_name,
    is_readonly,
    is_session_expired,
    absolute_delay,          -- 落后多少条日志
    queue_size,              -- 待同步的 part 数量
    log_pointer
FROM system.replicas;

-- Keeper 连接信息（需启用相关配置）
SELECT
    name,
    value
FROM system.zooserver
WHERE name IN ('zk_num_connections', 'zk_requests');
​

is_session_expired = 1 说明该副本与协调服务的会话断了，同步会暂停，这是最需要立刻处理的状态。queue_size 持续上涨说明有 part 拉不过来，要看网络和 Keeper 负载。absolute_delay 短暂增大是正常的，持续增大才是问题。

协调服务本身也要监控。ZooKeeper/Keeper 的关键指标包括：延迟、连接数、watch 数量、事务速率。Keeper 官方建议生产至少 3 节点，数据目录要独立磁盘并定期备份快照：

# 备份 Keeper 快照目录（生产配合定时任务）
cp -r /var/lib/clickhouse-keeper/snapshots /backup/keeper_snapshot_$(date +%Y%m%d)
​

最后记住：协调服务挂掉不会立刻丢数据（数据在本地 part 里），但副本同步、合并、mutation 都会停摆。所以它的监控优先级和 ClickHouse 本身一样高——命脉级别的组件，配得上命脉级别的关注。