ClickHouse Keeper 与 ZooKeeper

我现在越来越不把这个问题理解成“Keeper 能不能替代 ZooKeeper”，而更愿意把它看成一次关于组织边界的选择：你要的是 ClickHouse 专用协调层，还是平台级通用协调服务。

核心判断

如果你的协调需求主要就是服务 ClickHouse 自己，那我会把 ClickHouse Keeper 视为默认优先项；如果你的组织已经把 ZooKeeper 当作一套被多种系统共享的基础设施，或者确实依赖 ClickHouse 之外的 ZooKeeper 生态与工具链，那么继续使用 ZooKeeper 仍然是合理选择。

这个结论有一部分来自官方文档，也有一部分是我基于文档做的归纳。我觉得这种归纳方式比争论“谁更先进”更贴近真实生产环境。

两者的共同点

都能为 ClickHouse 提供复制元数据协调能力。
都能支撑 ReplicatedMergeTree、分布式 DDL 等依赖协调层的能力。
Keeper 在协议层面兼容 ZooKeeper，因此 ClickHouse 不需要为此改写自己的核心交互模型。

ClickHouse Keeper 的优势

更贴近 ClickHouse 运维模型：Keeper 是 ClickHouse 官方直接维护的协调服务，文档、配置与排障路径都围绕 ClickHouse 场景展开。
依赖面更小：对 ClickHouse-only 集群来说，不必再长期维护一套独立的通用协调中间件。
生产部署建议更直接：官方已经把 Keeper 纳入集群示例与部署文档，生产环境可独立部署在专门节点上。
能力边界更聚焦：它的设计目标不是支撑各种外围应用，而是把 ClickHouse 自身复制与协调路径跑稳。

ClickHouse Keeper 的代价与局限

不是通用 ZooKeeper 替身：官方文档明确提醒，外部集成不是 Keeper 的主要目标。
迁移不能混跑：同一 ClickHouse 集群里不能一部分走 ZooKeeper、一部分走 Keeper，只能做受控切换。
动态重配语义要重新核对：enable_reconfiguration 默认关闭，说明某些行为不能想当然地按 ZooKeeper 经验照搬。
运维团队仍需理解它：虽然它是原生组件，但依然涉及 quorum、server id、恢复模式、命令集和性能参数，不是零认知成本。

ZooKeeper 的优势

生态更广：如果你的协调层同时服务别的系统、工具或历史脚本，ZooKeeper 的通用性更强。
组织经验可能更成熟：很多团队已经有 ZooKeeper 的监控、升级、容灾与故障处理经验，这会降低切换风险。
跨系统复用更自然：当协调服务本来就是平台级公共组件时，继续沿用 ZooKeeper 往往更省组织成本。

ZooKeeper 的代价

对 ClickHouse-only 场景可能偏重：如果它只服务 ClickHouse，本质上是在为单一数据库长期维护一套额外基础设施。
配置与排障割裂感更强：数据库本身和协调层分属不同技术栈，问题定位往往跨两套系统。
新建 ClickHouse 集群时没有 Keeper 那么贴合官方默认路径：官方文档与集群示例已经把 Keeper 放到更中心的位置。

生产环境怎么选

适合优先选 Keeper 的情况

这是新建的 ClickHouse 集群。
协调层只服务 ClickHouse，不需要被其他系统共享。
你希望减少额外中间件种类，降低部署与排障面的复杂度。
你愿意接受 Keeper 的能力边界，并按 ClickHouse 官方建议来运维它。

适合继续选 ZooKeeper 的情况

现有组织已经把 ZooKeeper 作为公共基础设施稳定运行。
除 ClickHouse 外，还有其他系统或工具明确依赖 ZooKeeper。
你的现网剧本、监控体系和故障处理经验高度围绕 ZooKeeper 构建。
迁移窗口有限，当前没有足够收益支撑一次协调层切换。

只读表是协调层问题的信号

clickhouse-13-mistakes 里提到的 readonly tables 给这个主题补了一个很实用的故障视角：在自管复制环境里，如果节点失去和协调服务的连接，它可能无法继续参与复制，并拒绝写入。

这意味着 Keeper / ZooKeeper 的资源不足、混部抢资源或网络不稳定，最后可能不是以“协调层报警”这种清晰形式出现，而是以 ClickHouse 表突然只读的方式暴露。对我来说，这强化了一个判断：协调层不是数据库外面的旁路组件，而是复制写路径的一部分。

使用建议

如果你选 Keeper

生产环境尽量独立部署 3 节点或 5 节点 Keeper，不要默认和 ClickHouse Server 混部。
把 Keeper 当作显式运维对象，补齐监控、备份、恢复演练与版本升级流程。
开启 async_replication 之前先确认业务能接受新的确认路径与故障窗口。
涉及动态重配置时，先核对 Keeper 文档而不是沿用 ZooKeeper 旧经验。

如果你留在 ZooKeeper

明确自己保留它的理由是生态与组织复用，而不是“历史上一直这样”。
把 ClickHouse 侧依赖的 ZooKeeper 行为整理成最小必要集，避免隐含耦合越来越多。
保留未来迁移到 Keeper 的演练路径，尤其是快照转换和切换步骤。

一个更实用的选型标准

不要把这个问题理解成“哪个更高级”，而要理解成：

你需要的是ClickHouse 专用协调层，还是平台级通用协调服务；
你在意的是减少依赖面，还是复用现有生态与经验；
你面对的是新建集群，还是已有稳定系统的低风险演进。

在这个标准下，Keeper 和 ZooKeeper 的优缺点其实很对称：Keeper 赢在聚焦与集成，ZooKeeper 赢在通用性与历史沉淀。这个对称性恰恰说明，它们不是简单的新旧替代关系。

来源：clickhouse-keeper · clickhouse-replication-and-scaling · clickhouse-manage-and-deploy · clickhouse-13-mistakes

kaikai's wiki

探索