ClickHouse 读写分离方案

1、需求背景

• 当使用Replicated表的时候，集群里面只有一半的机器能提供查询；如果是通过分布式表写数据的，等于也只有一半的机器能提供写的服务，间接等于集群有一半是空闲的。
• 读写分离的方案，就是在使用Replicated表的时候，使一半的集群提供写服务（统称写replica），一半的集群提供读服务（统称读replica）；再利用Replicated表的复制特性，将数据从写replica同步到读replica。
• ClickHouse version > 19.6.2.11

2、具体实现

（1）读replica

• 配置：在CH的users.xml配置中，找到load_balancing配置为first_or_random

• first_or_random：默认使用shard里面的第一个replica，如果第一个replica失败则使用其他replica；

  
  image.png

（2）写replica

• 配置：写的时候不能再通过分布式表写了，需要直接写到对应的节点上。可以配置域名指向shard里面的其他写replica，例如上图的CH-IP2、CH-IP4，利用域名的轮训分发策略去写；或者利用第三方分发软件，例如nginx；或者入库的时候程序自己控制。

3、效果

1、通过上面的配置，写的时候，我们自己控制写到除第一个replica的其他replica上；在通过分布式表读的时候，就会自动把读请求分发到第一个replica上，再利用复制特性把数据同步到自己replica上。通过这样子的设计，使得读请求与写请求分开。
2、优点
（1）相比之前的普通集群配置，等于把空闲的资源利用起来，提供了集群资源利用率。
（2）读写互不干扰，单并发的写、读性能提升。
3、缺点
（1）相比普通的集群配置，当并发多查请求时，性能下降更厉害。假设集群有N台，则在多个请求过来的时候，可以理解集群有N台服务器能提供读服务；当使用这种架构的时候，则只有N/2台能提供服务，单台负载的请求数翻倍。
4、all

image.png

• 可以理解，当一台服务器可以抗的并发数为N，当并发数<N的情况下，读写分离优于普通架构（因为不受写影响）；当并发数 > N，读写分离的架构性能衰退得更厉害。
• 总体而言，读写分离架构适合集群并发数低、追求单个请求请求快的场景。在较高的并发请求情况下，则使用普通集群更合适。