复制的三种主流架构单主多主无主及其复杂度权衡

复制的目标是让通过网络连接的多台机器保留相同数据的副本，动机包括降低延迟（数据 离用户更近）、提高可用性（部分故障时仍能工作）、提升读吞吐量（更多机器分担读 请求）。数据不变的话复制很简单，难点全在于处理”变更”如何传播，几乎所有分布式 数据库都用以下三种方法之一。单主复制（基于领导者）：一个副本被指定为主库，只有 它能接受写入，写入后把变更以复制日志形式发给所有从库，从库按相同顺序重放；这是 最容易理解、不用操心冲突解决的方案，也是最流行的选择。多主复制：允许多个节点同时 接受写入，每个节点既是其他节点的主库、也是其他节点的从库；主要用于多数据中心场景 （每个数据中心一个主库，本地写入延迟低、能容忍数据中心整体离线）、需要离线工作的 客户端（每台设备是自己的主库）、以及协同编辑场景，但代价是必须处理”两处同时修改 同一数据”的写冲突。无主复制：完全放弃主库概念，客户端把写请求并行发给多个副本， 读请求也并行发给多个副本、靠版本号识别陈旧数据，最早由Amazon Dynamo带火，Riak、 Cassandra、Voldemort都是这一流派。三种架构的复杂度递增：单主最简单但只有一个写 入口是单点；多主和无主在节点故障、网络中断、延迟尖峰下更健壮，但代价是更难推理、 一致性保证更弱，且都要面对”如何解决并发写冲突”这个核心难题。

结构图：

flowchart LR
    A[单主复制] --> A1[唯一写入口, 简单, 无冲突问题]
    A1 -.主库是单点.-> A1
    B[多主复制] --> B1[多个写入口, 各地本地写延迟低]
    B1 -.必须处理并发写冲突.-> B1
    C[无主复制] --> C1[客户端并行写读多个副本, 靠版本号识别陈旧]
    C1 -.更健壮但一致性保证更弱.-> C1