1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

数据复制 = 在多个节点存副本

目的：
  ✓ 高可用（一个挂了，其他还能服务）
  ✓ 读扩展（多副本分担读压力）
  ✓ 就近访问（副本部署在不同地域，降低延迟）
  ✓ 容灾（异地备份）

代价：
  ✗ 一致性问题（副本间可能不一致）
  ✗ 写入开销（要同步到多个副本）
  ✗ 冲突（多副本同时改）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

一个主（Leader）负责写，多个从（Follower）复制

  客户端 → Leader（写）→ 复制 → Follower1, Follower2
  客户端 ← Follower（读）

特点：
  ✓ 写入无冲突（只有 Leader 写）
  ✓ 简单
  ✗ Leader 是写瓶颈和单点
  ✗ 主从延迟（异步复制时从节点数据滞后）

代表：MySQL 主从、Redis 主从、PostgreSQL 流复制、Kafka 分区

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

多个 Leader 都能写，互相复制

  Leader1 ←→ Leader2
    ↓           ↓
  副本          副本

特点：
  ✓ 写可用性高（一个 Leader 挂了，另一个还能写）
  ✓ 适合多数据中心
  ✗ 写冲突（两个 Leader 同时改同一数据）
  ✗ 冲突解决复杂

代表：CouchDB、多数据中心部署的 MySQL（双主）

1
2
3
4
5
6
7
8
9

没有 Leader，客户端写多个节点，读多个节点比对

  客户端 → 写 N 个节点（W 个成功即算成功）
  客户端 ← 读 N 个节点（R 个返回一致即最新）

  W + R > N 保证强一致（Quorum）
  典型：W=R=多数

代表：Cassandra、DynamoDB、Riak（Dynamo 风格）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

同步复制：
  Leader 写后，等所有 Follower 确认才返回客户端
  ✓ 强一致  ✗ 慢、一个 Follower 慢全拖慢

异步复制：
  Leader 写后立即返回，Follower 异步追赶
  ✓ 快  ✗ 数据可能滞后、Leader 挂了可能丢未同步数据

半同步复制：
  至少一个 Follower 同步确认，其他异步
  折中（MySQL 半同步复制）

  Redis 主从、MySQL 默认都是异步（性能优先）

1
2
3
4
5
6
7
8

基于语句：复制 SQL 语句（now()、rand() 等有问题）
基于行（Row）：复制数据行的变更（最常用，准确）
混合模式：语句 + 行
逻辑日志：复制逻辑变更（跨数据库兼容）

  MySQL binlog 支持 STATEMENT/ROW/MIXED
  Kafka 用消息本身做日志
  Redis 用命令/字节流

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

1. 最后写入获胜（LWW）
   用时间戳，新的覆盖旧的
   ✗ 时钟漂移导致丢数据
   ✗ 简单但会丢更新（适合可容忍的场景）

2. 向量时钟（Vector Clock）
   记录每个写操作的逻辑时钟
   能检测并发冲突，交给应用解决
   ✓ 不依赖物理时钟  ✗ 复杂

3. 应用层解决
   冲突版本都返回，应用合并（如购物车合并）
   代表：Riak、CouchDB

4. CRDT（Conflict-free Replicated Data Type）
   无冲突复制数据类型，自动可合并
   ✓ 自动解决冲突  ✗ 数据类型受限（计数器、集合等）
   代表：Redis（部分）、Automerge、Yjs（协同编辑）

1
2
3
4
5
6
7
8

Gossip 核心思路：
  每个节点周期性随机挑几个节点，交换状态信息
  经过多轮，信息扩散到全网

  一轮 Gossip：
    Node A 随机选 B → 交换彼此知道的所有节点状态
    B 又选 C 交换 → ...
    O(log N) 轮后，全网收敛

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Gossip 的特点：
  ✓ 极高可扩展性（节点数再多也 O(log N) 收敛）
  ✓ 容错（节点挂了不影响传播）
  ✓ 去中心化（无主节点）
  ✓ 最终一致
  ✗ 不是强一致（有传播延迟）
  ✗ 可能传播过时信息（靠版本号解决）

代表：
  Cassandra — 节点状态、集群拓扑用 Gossip
  Consul    — 成员管理、故障检测用 Gossip
  Redis Cluster — 节点发现用 Gossip
  比特币     — 区块/交易传播
  HashiCorp Serf — Gossip 库

1
2
3
4
5
6

Gossip 还用于故障检测（Phi Accrual Failure Detector）：
  节点间互相发心跳（Gossip 带心跳）
  一段时间收不到某节点心跳 → 标记 suspect → 确认 down
  多个节点独立判断，避免单点误判

  比单纯超时更鲁棒（自适应、分布式）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

方案：
1. UUID
   ✓ 无中心、全局唯一  ✗ 长（128位）、无序、索引差

2. 雪花算法（Snowflake）
   64位 = 时间戳(41) + 机器ID(10) + 序列号(12)
   ✓ 趋势递增、高性能、无中心
   ✗ 依赖时钟（时钟回拨问题）

3. 数据库自增（分段）
   各节点分配不同 ID 段
   ✓ 简单  ✗ 依赖 DB

4. Redis INCR
   ✓ 简单、递增  ✗ 依赖 Redis、单点

5. 号段模式（Leaf、Tinyid）
   预分配 ID 段，本地消费，用完再取
   ✓ 高性能  ✗ 实现稍复杂

  通用推荐：雪花算法 / 号段模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

单机限流（内存）管不到多机，需要分布式限流：

1. Redis + Lua（集中式）
   所有请求到 Redis 计数，Lua 保证原子
   ✓ 准确  ✗ Redis 单点/性能瓶颈

2. 令牌桶（Redis 实现）
   按速率生成令牌，请求消耗令牌

3. 本地限流 + 中心同步
   各节点本地限流（配额的 1/N），定期同步
   ✓ 性能好  ✗ 不精确

  .NET 8 内置限流 + Redis 可做分布式