解决：一个是循环复制问题我们为

每个q集群标记了不同的，并且记录了每个的初始写入，同步服务会过滤掉与目标集群相同的数据，以避免发生循环复制

还有一个是数据冲突问题我们一开始是通过业务层面保证在每个地域运行过程中，还是会有一些极端场景可能会出现两个地域并发写同一个比如像机房网络故障场景，业务会把故障机房的所有写入都切到正常机房但由于我们的集群间复制是异步的，可能故障机房有一些最新的变更还没有复制到正常机房的集群而如果在业务将写切换到正常机房后，又写入了相同的不同变更，就会产生两个同步集群的数据冲突

在机房网络恢复之后，业务还是要

把一部分流量切回到之前故障的集群上，恢复到跨地域容灾的架 电话号码数据库 构但由于两个集群可能已经有数据冲突了，所以，在业务切回之前，就需要对数据做冲突校验和修复但是对大数据量集群来说，数据校验和修复的耗时可能会长达数天在这样长的时间内，只有一个单地域集群来支撑业务，无论是从容灾还是容量的角度来看，都是有较大风险的9双向同步冲突自动解决为了解决上述的双向同步数据冲突问题，我们实现了一个基于数据写入本地时间的ww冲突自动解决功能

如上图所示，在时刻的值在、两个集

群都是时刻，的值在集群更新成了但是在集群的新值 如何消除电话推销 还没复制到集群的时候，集群在时刻把的值更新成了这时候、集群会互相向对方复制各自写入的新值，集群收到集群的值后，会发现集群的更新时间大于自己（>），它就会更新自己的值为；集群也会收到集群复制过来的值，但它会发现这个值的更新时间小于自己本地值的更新时间（<），就会忽略这个复制请求

通过这样一个基于更新时间的

策略，就可以达到最终一致性上述方案看起来简单，但是在复杂、大规模的业务场景下，还有很多问题要处理，所以，我们还做了以下的工作：保存最近更新的时间戳：当发生时钟回退时，我们会继续使用自己保存的时间戳，避免使用本地回退的时间导致数据也跟着发生了回退（：对于时钟回退问题，我们调研过最新的时钟同步不会像以前一样造成本地时钟的回退或跳变，现在它通过把时钟调快或调慢来完成类似的调整，所以，前述关于时钟回退的解决方案在最新的同步机制下就不是必要的了

不过，为了保证我们的服务

在任何系统下都能正常运行，我们最终还是实现了这个功能）记录写入数据的集群：我们会为所有写入的保存写入的集群当两个值的更新时间相同时，我们会比较集群，如果也相同，我们就知道是同一个集群先后写入但获取到相同本地时间的数据，会允许其写入；如果不同，我们仅会让集群更大的值写入，来保证数据最终一致性

由复制操作改为复制变更后

的数据：像类接口，集群的时刻通过变成了，然后集群时刻通过变成了集群收到集群的复制时，因为时间戳比自己的本地值大，它会执行变成5；然后集群收到集群的复制时，因为时间戳比自己的本地值小，它会把这个复制请求给忽略掉，就造成了数据冲突