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的数据完成了同步。
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各自的分区
整个执行过程中zk只是作为消息通知的手段，clickhouse表数据的传输并没有通过zk进行，zk的压力其实不大，此外，对于ReplicateMergeTree表的查询操作并不需要zk的参与。
