clickhouse 副本ReplicateMergeTree实现原理及导致的数据一致性问题

ReplicateMergeTree同步原理

ReplicateMergeTree可以通过和zk结合，把数据同步到对应的副本节点中，而且同步是相互的，也就是说从A节点写入的数据会同步到B节点，从B节点写入的数据也会写入到A节点中，典型的Mul-Master架构。通过一个分片多个副本的形式可以分摊读和写的负载，我们看一下同步的原理：

a. insert数据：假设A节点进行数据插入，首先A节点本地会创建一个新的目录分区，然后他会把这个分区目录的信息推送到zk的log目录节点下，目的是为了通知B节点来获取该分区的数据，B节点会监听zk的log节点的变更通知，让得知是要去A节点同步数据分区数据时，他首先先把这个消息发送到他对应的zk上面的任务执行队列，B本身会按照zk上面的执行队列的顺序顺序执行各个操作，自然当获取到是要去A同步数据分区数据时，他会和A节点建立数据连接，希望从A那里下载到该分区数据，等到A返回对应的分区数据时，B会在本地创建一个名称一模一样的目录分区数据,自此insert的数据完成了同步。

Insert数据插入操作时多个副本之间是有存在副本一致性问题的，也就是同步期间副本0和副本1的数据是不一致的，所以对于使用multi-master进行写多个副本的操作时，需要意识到在一定的时间内多个副本之间的数据是不一致的，所以选择这种方案需要考虑到数据不一致的问题

b. merge合并数据: 这个操作需要从A和B中通过zk选举出主节点，假设A是主节点，B是副节点，当B执行optimize table操作合并数据分区时，B首先和主节点A直接建立连接，告诉A主副本负责制定merge合并计划，当A收到B的制定merge计划的请求后，A制定了merge计划，比如把2020_0_0_0和2020_2_2_1合并成2020_0_2_2，他会把这个执行计划推送到zk的log节点中，这样A和B监听到zk的log节点执行计划后会分别把这个执行计划推送到各自在zk上的queue任务队列中，然后A和B各自执行各自的任务队列操作时，就会各自按照执行计划merge各自的分区

c. update/delete数据：假设A节点进行数据删除操作Alter table XX delete id=100，首先A节点会把这个操作组合成一个消息（包含mutationid）发送到zk中，此后节点A和B会监听zk中的mutation节点的变更，假设此时B节点是主节点，所以B节点会响应这个数据变更的消息并指定具体的数据更新计划，比如目录文件从202209_0_0_1在进行了delete具体操作后变成202209_0_0_1_mutationid,然后B节点会发送这个具体的数据更新消息到zk中，此时A和B节点会同时监听到具体的数据变更消息，然后在各自的本地磁盘中进行数据的修改/删除操作,自此update/delete的数据完成了同步。

update/delete数据修改操作时多个副本之间是有存在副本一致性问题的，也就是同步期间副本0和副本1的数据是不一致的，所以对于使用multi-master进行修改删除多个副本的操作时，需要意识到在一定的时间内多个副本之间的数据是不一致的，所以选择这种方案需要考虑到数据不一致的问题

整个执行过程中zk只是作为消息通知的手段，clickhouse表数据的传输并没有通过zk进行，zk的压力其实不大，此外，对于ReplicateMergeTree表的查询操作并不需要zk的参与。

注意事项：

正像在文章中多次提到过的，insert/update/delete数据修改操作时多个副本之间是有存在副本一致性问题的，也就是同步期间副本0和副本1的数据是不一致的，所以对于使用multi-master进行新增修改删除多个副本的操作时，需要意识到在一定的时间内多个副本之间的数据是不一致的，所以选择这种方案需要考虑到数据不一致的问题
解决方式一：我们意识到多个副本之间数据的差异，并能接受这种差异，接受这种差距意味着A节点写入的数据B节点查不到，B节点写入的数据A节点中也不存在，不过这种方式可以写负载均衡，也就是可以支持同时写多台服务器
解决方式二：我们类似mysql主从一样，一台服务器作为作为写，另一台服务器只作为读，写操作只对某台服务器进行，对数据写入敏感的读数据也是只从主服务器进行读取