为何MySQL Master-Master架构能够提升写入性能？

你提到的强一致场景下Master-Master的额外复杂度、冲突问题是客观存在的，但现有认知存在几处典型疏漏：

• 混淆了不同一致性等级下的Master-Master设计逻辑：多数对外宣传跨站点部署优势的Master-Master架构，默认适配的是最终一致性场景，而非强一致场景。你默认预设了架构必须保证强一致，但实际大量业务场景（比如用户个性化偏好设置、非实时内容字段更新）不需要强一致，这类场景下不需要跨站点实时加锁，仅靠异步同步+冲突兜底规则（比如最后写入获胜LWW、自定义合并逻辑）即可运行，额外复杂度远低于强一致场景，多活就近写入的收益远高于主从架构（主从架构跨站点写需要回源唯一主节点，延迟极高）。
• 忽略了分片路由规则对Master-Master的优化作用：生产环境落地的跨站点Master-Master几乎不会放开所有节点写所有数据的权限，大多会按业务维度、用户归属维度做分片路由。比如按用户所在地区分片，欧洲用户的写请求只会路由到欧洲站点的Master节点，亚洲用户的写请求只会路由到亚洲站点的Master节点，不同分片之间不存在数据重叠，自然不会产生冲突，也不需要跨站点加锁，只有极少量跨分片操作需要额外处理，整体额外开销和复杂度远低于无分片的全量Master-Master设计。
• 低估了主从架构跨站点部署的隐式成本：主从架构如果要实现跨站点高可用，同样需要处理主节点宕机后的选主切换、数据一致性校验、脑裂规避等问题，这部分复杂度并不比经过优化的Master-Master低。如果业务本身有跨站点就近写的需求，主从架构需要把所有写请求转发到唯一主节点，产生的跨站点网络延迟、带宽成本反而比Master-Master更高。
• 对冲突问题的场景适配性认知有偏差：你提到的库存抢购这类高并发强一致冲突场景，本身就不是Master-Master架构的推荐适用场景，绝大多数宣传Master-Master跨站点优势的方案都会主动规避这类业务，或者通过分布式锁、专属分片路由的方式把冲突概率降到极低，不会直接允许多个节点同时修改同一个库存字段。

补充：如果业务确实要求全场景强一致，你提到的Master-Master的额外开销、冲突问题全部成立，这类场景优先选择单主架构性价比更高。

内容的提问来源于stack exchange，提问作者Tal Humy