多机房数据同步的两种主流方案，及Cassandra的Read Repair冲突修复机制

分布式系统跨机房同步数据主要有两种主流方案：一种是由节点自身负责机房间同步（Cassandra、CouchBase、Riak的做法），写入某个机房的协调节点后，由这个节点异步负责把数据同步到其他机房的对应节点，客户端只需要在本地写入成功即可返回，完全不需要感知跨机房延迟；另一种是引入一个外部队列专门负责机房间的数据同步（Yahoo Pnuts的做法，Bada自己采用的也是这个思路，基于内部的Kafka/QBus消息队列实现）。以Cassandra为代表的”节点自同步”方案在实现最终一致性的同时，还搭配了一个巧妙的冲突修复机制——Read Repair：读取时会同时读本地的多个副本，如果发现副本间数据不一致，就选取时间戳最新的版本重新写回，让数据在读取的过程中顺带完成自我修复，而不需要专门起一个后台任务持续巡检所有数据。这个”读时修复”的思路可以推广到多机房场景：只要在不同机房间也周期性地跑对比任务，check不同机房之间的数据差异并按同样的规则修复，就相当于把单机房内部的Read Repair思想复用到了跨机房层面。这个案例的普遍价值在于，”最终一致性”系统里数据不一致几乎是必然会发生的常态，与其追求杜绝不一致，不如设计一套廉价、可重复触发的修复机制（读时顺带修复、定期巡检修复），让不一致的窗口能够被持续、自动地收敛，而不是依赖人工介入。