ClickHouse集群在eBay事件监控平台的可用性和扩展性探索(3)

ClickHouse集群在eBay事件监控平台的可用性和扩展性探索

2.2 ClickHouse集群的横向扩展

在问题描述的架构图中我们可以看到，ClickHouse集群横向扩展的瓶颈在于整个集群都在用Zookeeper来做数据的同步，而随着ClickHouse横向扩展，shard越来越多，ZK的压力只会有增无减。然而实际上除了分布式DDL指令的执行是整个集群水平的，数据同步实际上只是shard水平进行的，这意味着如果ClickHouse集群的不同shard配置不同的zk，ClickHouse的横向扩展就不再是问题了。

在我们进行调研ClickHouse 集群配置Muiti-zk的方案时，同时关注到社区在v21.3开始，ClickHouse Keeper可以代替ZooKeeper成为数据进行同步所依赖的一致性协调服务，Keeper使用的是和ClickHouse相同的code base,基于RAFT一致性算法的C++实现，可以提供线性读和线性写，算法本身非常成熟，社区也有多种基于不同编程语言的版本实现。默认情况下，ClickHouse Keeper提供了和ZooKeeper相同可见性保证，即线性写和非线性读。并且Keeper实现了一套和ZooKeeper完全兼容的client-server通信协议，这意味着任何的标准ZK client都可以和Keeper server进行通信。

另外非常重要的一点是，Keeper既可以作为一个独立的application进行单独部署，也可以内置在ClickHouse server里面一同启动，因此多种不同的deploy结构可以被支持。

鉴于我们遇到的横向扩展的问题，我们可以使集群中的不同的shard使用单独的一致性协调服务来进行数据的同步。在这种部署模式下，Keeper内置在ClickHouse server中一同启动，减少了外部依赖的维护。

但对于一个新引入的模块，我们必须要有足够的知识能够运维，尤其是在troubleshooting或者是在故障发生时恢复服务时。虽然相对于ZooKeeper来讲，Keeper完全是一个全新的模块，但是Keeper作为Zookeeper的替代品，却是非常友好的。

1.Keeper和zk具有完全相同的内部状态（Znode/ACL/Watch…），完全可以说是基于RAFT算法实现的ZooKeeper。

2.Keeper实现了和ZK完全相同的client-server通信协议，这意味着任何标准的zkClient可以和ClickHouse Keeper 交互以获取其内部状态。

3.和ZK提供了几乎一样的4lw(4 letter word)命令。

因此从定位问题的角度来看，Keeper和Zk一样简单能随时获取运行状态。但是这还不够，我们需要能够通过Keeper的异常状态，设置一些告警能及时收到通知，以做出处理和服务恢复，如果能在Grafana上建立dashboard展示Keeper的状态就更好了。但是当时Keeper并没有任何metrics暴露出来。

于是为了推进Keeper在事件监控平台上的应用，我们做了相关change将需要的内部信息通过metrics的形式和其他的监控信息一同暴露出来并贡献回了社区，并在Sherlock.io Grafana上建立了Keeper的dashboard: