数据系统检测到复制更改日志中的冲突，它就调用冲突处理程序。或是在应用程序读取的阶段检测到冲突时，会将这些数据的多个版本将返回应用程序。应用程序可以提示用户或自动解决冲突，并将结果写入数据库。（Cassandra与CouchDB就是采取了这种机制）
多Leader机制的复制拓扑
两个Leader进行同步时，拓扑结构十分简单。但是一旦扩展到4,5个Leader，之后多个Leader之间的同步结构又应该是怎么样的呢？（虽然在实践中，很少采用这样的架构）
最一般的拓扑结构是图（c），其中每个节点都将其写入传递给所有的节点。而（a）或（b）采用了环形或星型的结构来减少网络的流量。在环形和星形拓扑中，在到达所有副本之前，写入可能需要经过几个节点。因此，节点需要转发它们从其他节点接收到的数据更改。为了防止无限复制循环，每个节点都被赋予唯一的标识符，并且在复制日志中，每个写入都用它经过的所有节点的标识符标记。当一个节点接收一个带有自己标识符的数据更改时，该数据更改将被忽略，因为节点知道它已经被处理了。
环形和星形结构存在的一个问题是，如果有一个节点失效，会中断其他节点之间的同步消息流，而因为它不允许消息沿着不同的路径传播，造成了单点故障。但是All pass的结构也会带来一些新的问题，由于网络拥塞的原因，各个节点的信息接收顺序不一致，如下图所示：
Client A将行插入到一个Leader 1的表，和Client B在Leader 3之中进行更新。而Leader 2收到了不同顺序的写操作：update操作出现在了insert操作之前。为了正确地排列这些事件，我们可以使用一种称为多版本向量控制（MVCC）的技术。至于什么是MVVC，我们下一篇继续来梳理~~（ 不是我故意卖关子啊，只是怕写的太长你们懒得看~~~）
