多主复制的最大问题：可能发生写冲突，这是必须要解决的。
如两个用户同时编辑wiki，如图-7：
- User 1将页面标题从A-》B
- 且User 2同时将标题从A-》C
每个用户的更改都成功提交到本地主节点。但异步复制到对方时，发现存在冲突。正常的主从复制则无此问题。
若为主从复制DB，第二个写请求将：
- 被阻塞直到第一个写完成
- 或被中止，强制用户必须重试
而多主节点复制时，这两个写都成功，且只能在稍后时间点才能异步检测到冲突，那时再要求用户解决冲突，为时已晚！
理论上能做到同步冲突检测：等待写请求完成对所有副本的同步，再通知用户写成功。但这就失去多主的优点：允许每个主节点独立接受写请求。所以，若确需同步冲突检测，应考虑使用单主节点的主从复制！
3.2.2 避免冲突处理冲突的最理想策略：避免它们。若应用层能保证对特定记录的所有写请求都通过同一主节点，那就不存在冲突。实践中，由于很多主节点复制模型所实现的冲突解决方案很辣鸡，因此直接避免冲突才是推荐方案。
若用户需编辑自己的数据，可确保特定用户的请求始终路由到特定IDC，并使用该IDC的主节点读、写。不同用户可能对应不同主IDC（如CDN），但用户角度，这基本等价于主从复制模型。
但有时可能需更改事先指定的主节点，可能因为：
- IDC故障，需将流量重新路由到另一个IDC
- 或用户已漫游到另一个位置，接近了不同IDC
此时，避免冲突的方案失效，必须要有方案应对不同主节点同时写入的可能。
