Distributed on 纪伟的个人博客

分布式系统学习笔记（五）：复制与 Gossip

Thu, 21 May 2026 10:00:00 +0800

写在前面

本文是分布式系列收官篇，讲数据复制（多副本如何同步）和 Gossip 协议（最终一致的传播机制），顺带讲分布式 ID 和限流。这些是 Cassandra、Redis Cluster、Consul、比特币网络背后的技术。

一、为什么要复制

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


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

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

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

二、三种复制架构

2.1 主从复制（Single-Leader）

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


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

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

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

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

2.2 多主复制（Multi-Leader）

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


多个 Leader 都能写，互相复制

 Leader1 ←→ Leader2
 ↓ ↓
 副本 副本

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

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

2.3 无主复制（Leaderless）

1
2
3
4
5
6
7
8
9


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

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

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

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

三、同步 vs 异步复制

 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（协同编辑）

六、Gossip 协议（流言协议）

最终一致系统的数据传播机制，像病毒扩散/流言传播。

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 库

Gossip 与故障检测

1
2
3
4
5
6


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

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

七、分布式 ID

分布式系统需要全局唯一 ID：

 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 可做分布式

九、小结

复制架构：主从（单Leader）、多主（多Leader）、无主（Leaderless + Quorum）
复制方式：同步（强一致慢）、异步（快有延迟）、半同步（折中）
冲突解决：LWW（简单丢数据）、向量时钟、应用层、CRDT（自动）
Gossip：流言式传播，O(log N) 收敛，最终一致，高可扩展
分布式 ID：雪花算法（趋势递增无中心）、号段模式
分布式限流：Redis + Lua 集中式、本地+中心同步

系列总结

分布式系统五篇完结：

CAP 与一致性：CP vs AP，BASE，一致性模型
Raft 共识：Leader 选举 + 日志复制 + Quorum，现代 CP 系统标配
分布式锁：Redis（AP 快）/ ZK·etcd（CP 可靠）
分布式事务：2PC/TCC/Saga/本地消息表，优先最终一致
复制与 Gossip：主从/多主/无主，Gossip 最终一致传播

核心心法：分布式系统的本质是"在不可靠的网络和节点上，构建可靠的协同"。CAP、共识、复制、一致性，都是在回答"如何取舍"的问题。没有完美方案，只有适合场景的方案。

分布式系统学习笔记（四）：分布式事务

Wed, 20 May 2026 10:00:00 +0800

写在前面

本文讲分布式事务——跨多个服务/数据库如何保证数据一致。这是分布式系统最难的问题之一。本文梳理各种方案（2PC、TCC、Saga、本地消息表、事务消息），以及它们各自的取舍。

一、问题：本地事务不够用了

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


单库：用数据库事务（ACID）
 BEGIN; 扣钱; 加积分; COMMIT; -- 要么全成功，要么全回滚

微服务/分库后：
 下单 = 订单服务（订单库）+ 库存服务（库存库）+ 积分服务（积分库）
 三个独立数据库，本地事务管不到彼此

 问题：
 订单创建成功，库存扣减失败 → 数据不一致
 积分服务宕机 → 订单已建但积分没加
 网络超时 → 不知道对方成功没

 需要分布式事务：跨库/跨服务保证最终一致

二、2PC（两阶段提交）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


协调者（Coordinator）协调多个参与者（Participant）：

阶段1：Prepare（准备）
 协调者问所有参与者："能不能提交？"
 参与者执行操作、锁资源、写日志，回复 Yes/No

阶段2：Commit / Rollback
 全部 Yes → 协调者发 Commit，参与者提交
 任一 No → 协调者发 Rollback，参与者回滚

 XA 协议就是 2PC

1
2
3
4
5
6
7
8


优点：强一致（所有参与者要么全提交要么全回滚）
缺点：
 ✗ 同步阻塞：prepare 阶段所有参与者锁资源，直到 commit
 ✗ 协调者单点：协调者挂了，参与者卡死
 ✗ 数据不一致：commit 阶段部分参与者收到、部分没收到
 ✗ 性能差：两轮网络 + 锁资源

 实际很少用（性能太差），银行等强一致场景偶用

3PC（三阶段提交）

1
2
3


2PC + CanCommit 阶段 + 超时机制
 减少阻塞、降低不一致
 但更复杂、轮次更多，实际很少用

三、TCC（Try-Confirm-Cancel）

业务层面的两阶段，每个服务实现三个方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Try — 预留资源（冻结库存、冻结金额）
Confirm — 确认提交（扣减冻结的）
Cancel — 取消（释放冻结的）

下单 TCC：
 Try： 订单（创建待确认）、库存（冻结10个）、积分（预加100）
 全部 Try 成功 → Confirm
 Confirm：订单（确认）、库存（扣减冻结）、积分（实加）
 任一 Try 失败 → Cancel
 Cancel： 订单（取消）、库存（解冻）、积分（撤销）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


优点：
 ✓ 无全局锁，性能好
 ✓ 最终一致

缺点：
 ✗ 业务侵入大（每个服务要写 Try/Confirm/Cancel 三套逻辑）
 ✗ 要保证 Confirm/Cancel 幂等（可能重试）
 ✗ 要处理空回滚、悬挂（Try 没到却收到 Cancel）

适用：核心交易（支付、扣库存），对一致性要求高
 框架：Seata-TCC、Hmily

四、Saga

把长事务拆成一串本地事务，每步有对应的补偿操作：

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


下单 Saga：
 T1 创建订单 ── 失败补偿 C1（取消订单）
 T2 扣减库存 ── 失败补偿 C2（恢复库存）
 T3 加积分 ── 失败补偿 C3（扣积分）
 T4 发优惠券 ── 失败补偿 C4（收回券）

 正向：T1 → T2 → T3 → T4
 T3 失败 → 反向补偿：C2 → C1（已执行的逐步回滚）

两种实现：
 编排式（Choreography）：服务间事件驱动，无中心
 协调式（Orchestration）：有中心协调器（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


优点：
 ✓ 每步是本地事务，无长锁
 ✓ 适合长流程业务

缺点：
 ✗ 没有隔离性（中间状态可见，可能脏读）
 ✗ 补偿逻辑复杂（不是所有操作都能完美补偿，如发短信）
 ✗ 需保证补偿幂等

适用：长流程业务（旅行预订、订单履约）
 框架：Seata-Saga、Camunda

五、本地消息表（最终一致，最常用）

把分布式事务降级为"本地事务 + 消息"，保证最终一致：

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


思路：
 A 服务执行本地业务 + 写一条"消息"到本地消息表（同一个本地事务）
 → 本地事务保证业务和消息一起成功
 后台定时扫描消息表 → 投递到 MQ / 调用 B 服务
 → B 处理成功 → 删除/标记消息
 → 失败重试

 A（扣钱）+ 本地消息表（加积分消息） ──同事务──→ 
 ↓ 定时扫描
 MQ / 调用 B
 ↓
 B（加积分）→ ACK → 删除消息

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


优点：
 ✓ 简单可靠，不用重型框架
 ✓ 最终一致
 ✓ 解耦（A 不直接依赖 B）

缺点：
 ✗ 消息表要自己维护
 ✗ 定时扫描有延迟
 ✗ B 必须幂等（消息可能重复投递）

适用：绝大多数最终一致场景（最接地气）

六、事务消息（RocketMQ）

类似本地消息表，但 MQ 内置支持，不用自己维护消息表：

1
2
3
4
5
6
7
8


RocketMQ 事务消息：
 1. 发送「半消息」到 MQ（消费者看不到）
 2. 执行本地事务（扣钱）
 3. 本地事务成功 → 提交半消息（消费者可见）
 本地事务失败 → 回滚半消息
 4. 如果没收到提交/回滚 → MQ 回查本地事务状态

 本质：把"本地事务 + 发消息"做成原子

1
2
3


优点：不用维护消息表，MQ 托管
缺点：依赖 RocketMQ（其他 MQ 没这功能）
适用：用 RocketMQ 的项目

七、方案对比

1
2
3
4
5
6
7


方案 一致性 性能 复杂度 业务侵入 适用
────────────────────────────────────────────────────────
2PC/3PC 强 差 中 低 强一致（银行）
TCC 强 好 高 高 核心交易
Saga 最终 好 中 中 长流程业务
本地消息表 最终 好 低 中 大多数场景
事务消息 最终 好 低 中 RocketMQ 项目

八、最佳实践：尽量避免分布式事务

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


分布式事务成本高，最优解是"不引入它"：

1. 合理的服务/库拆分
 强相关的数据放一起（同库同事务）
 只有真正独立的才拆服务

2. 最终一致 + 幂等
 大多数场景不需要强一致，最终一致 + 重试幂等就够

3. 事件驱动解耦
 服务间用事件/消息，而非同步调用
 天然异步、可重试

4. 业务容忍
 设计上容忍短暂不一致（如积分晚几秒到账）

 能用本地事务就用本地事务
 实在要分布式 → 优先最终一致（本地消息表/事务消息）
 核心强一致 → TCC

九、小结

2PC：强一致但阻塞、单点、性能差，少用
TCC：Try/Confirm/Cancel 业务两阶段，性能好但侵入大
Saga：长事务拆串 + 补偿，适合长流程，无隔离
本地消息表：本地事务 + 消息 + 重试，最常用的最终一致方案
事务消息：RocketMQ 内置的原子"业务+发消息"
核心：强一致用 TCC/2PC，最终一致用消息表/事务消息
最佳实践：尽量避免分布式事务，优先最终一致 + 幂等

下一篇讲复制与 Gossip 协议。

分布式系统学习笔记（三）：分布式锁

Tue, 19 May 2026 10:00:00 +0800

写在前面

本文讲分布式锁——多个服务/节点之间如何互斥访问共享资源。它有几种经典实现（数据库、Redis、Zookeeper、etcd），各有优劣。理解它们的差异，才能在不同场景选对方案。

一、为什么需要分布式锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单机：用 lock / Mutex / 信号量（进程内）

分布式：多个进程/机器要互斥
 单机锁管不到其他机器
 需要一个"全局可见"的锁

典型场景：
 - 防止重复操作（下单、扣库存、发券）
 - 限流（全局 QPS）
 - 选主（只一个节点执行定时任务）
 - 资源独占（同时只一个能改配置）

1
2
3
4
5
6
7


分布式锁的必要条件：
 ✓ 互斥（Mutual Exclusion）— 任意时刻只有一个客户端持有
 ✓ 避免死锁 — 持有者崩溃，锁要能自动释放
 ✓ 可重入（可选）— 同一持有者可重复获取
 ✓ 高可用 — 锁服务不能单点
 ✓ 高性能 — 加锁/解锁要快
 ✓ 公平性（可选）— 按请求顺序获取

二、实现方式对比

1
2
3
4
5
6


方式 一致性 性能 可靠性 复杂度 适用
──────────────────────────────────────────────────────────
数据库 强 中 中 低 简单场景
Redis 弱(AP) 极高 中 低 高并发、容忍偶尔失效
Zookeeper 强(CP) 中 高 中 强一致、可靠
etcd 强(CP) 高 高 中 云原生、K8s

三、数据库实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 方式一：唯一索引（加锁 = 插入，解锁 = 删除）
INSERT INTO locks(resource, owner, expire_at) VALUES('order:123', 'uuid', NOW()+10s);
-- 插入成功 = 获取锁；唯一冲突 = 被占
DELETE FROM locks WHERE resource='order:123' AND owner='uuid';

-- 方式二：悲观锁（SELECT ... FOR UPDATE）
BEGIN;
SELECT * FROM account WHERE id=1 FOR UPDATE; -- 加行锁
-- 业务
COMMIT;

1
2
3


优点：简单，不用引入新组件
缺点：性能差（DB 是瓶颈）、过期清理麻烦、FOR UPDATE 占连接
适用：并发不高、已有数据库、不想引入 Redis/ZK

四、Redis 实现

1
2
3
4
5
6
7
8


# 加锁：SET key value NX EX（原子）
SET lock:order:123 <owner_uuid> NX EX 10
# NX：不存在才设置（互斥）
# EX 10：10 秒过期（防死锁）
# 返回 OK = 获取成功；nil = 已被占

# 解锁：必须验证 owner 再删（Lua 保证原子）
# 否则可能删掉别人的锁

1
2
3
4
5
6


-- 解锁脚本（原子）
if redis.call('get', KEYS[1]) == ARGV[1] then
 return redis.call('del', KEYS[1])
else
 return 0
end

Redis 锁的问题

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


问题1：业务执行超过锁过期时间
 锁到期自动释放，别的客户端拿到锁 → 两个客户端同时执行
 解决：看门狗续期（定时延长过期时间）
 Redisson 框架自带看门狗

问题2：Redis 主从切换丢锁
 主节点加锁成功 → 还没同步到从 → 主挂了 → 从升主（没锁数据）→ 别人能加锁
 解决：Redlock（向多个独立 Redis 实例加锁，多数成功才算成功）

问题3：Redlock 的争议
 Martin Kleppmann 认为 Redis（AP）做锁不可靠
 因为 GC 停顿、时钟漂移可能导致锁失效
 Redis 作者 antirez 反驳（认为实际够用）

1
2
3
4
5


Redis 锁的定位：
 ✓ 高性能、高并发
 ✗ 不是绝对可靠（AP 系统的特性）
 适用：对偶尔失效容忍的场景（如限流、防重复提交）
 不适用：绝对不能错的场景（如扣款、扣库存）→ 用 ZK/etcd

五、Zookeeper 实现

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


ZK 锁基于「临时顺序节点」+ Watch：

1. 创建顺序临时节点 /lock/node-0001, /lock/node-0002 ...
2. 判断自己是不是序号最小的
 - 是 → 获得锁
 - 否 → 监听前一个节点（只监听前一个，避免羊群效应）
3. 前一个节点删除（释放锁）→ 自己被唤醒 → 成为最小 → 获得锁
4. 持有者崩溃 → 临时节点自动删除 → 后继者被唤醒

特点：
 ✓ 强一致（ZAB 共识）
 ✓ 公平锁（顺序节点）
 ✓ 会话失效自动释放（临时节点）
 ✓ 无看门狗问题（会话心跳保活）
 ✗ 性能不如 Redis（CP，要多数确认）

1
2
3


羊群效应（Herd Effect）：
 ✗ 所有等待者都监听同一个节点 → 释放时全部唤醒抢锁 → 惊群
 ✓ 改进：每个等待者只监听「前一个」节点 → 顺序唤醒

六、etcd 实现

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


etcd 锁基于 Lease（租约）+ 事务（TXN）+ Revision（全局递增版本）：

1. 创建带 Lease 的 key（Lease 保活，崩溃自动过期）
2. 用事务获取所有锁 key，判断自己 Revision 是否最小
 - 是 → 获得锁
 - 否 → 监听前一个 key
3. 类似 ZK 的顺序等待

特点（类似 ZK）：
 ✓ 强一致（Raft）
 ✓ Lease 自动过期（防死锁）
 ✓ 比 ZK 更轻量、性能更好、云原生标配
 K8s 的分布式锁多用 etcd（或基于 etcd 的 leader election）

1
2
3
4
5
6


// etcd 分布式锁示例（Go concurrency 包）
m, err := concurrency.NewSession(client)
l := concurrency.NewMutex(m, "/lock/order/123")
l.Lock(ctx) // 加锁
defer l.Unlock(ctx)
// 业务

七、CP vs AP 锁的本质区别

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


Redis 锁（AP）：
 返回"加锁成功"时，可能主从还没同步
 极端情况下锁可能失效（但你以为成功）
 → 快，但不可靠

ZK / etcd 锁（CP）：
 返回"加锁成功"时，数据已通过共识写入多数节点
 强一致保证，不会假成功
 → 可靠，但慢

选择：
 需要绝对可靠（金融、库存）→ CP（ZK/etcd）
 容忍偶尔失效、追求性能 → AP（Redis）

八、使用建议

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


场景 推荐
──────────────────────────────────────────────────
高并发、容忍偶尔失效（限流） Redis
防重复提交、幂等 Redis
扣库存、扣款（绝对不能错） ZK / etcd / 数据库
选主（Leader Election） ZK / etcd
配置/资源互斥 etcd（云原生）/ ZK

通用建议：
 优先用成熟框架（Redisson、curator、etcd concurrency）
 别自己造轮子（边界情况极多）
 锁要设过期时间 + 校验 owner
 业务要考虑"锁失效"的兜底（幂等）

九、小结

必要条件：互斥、防死锁、高可用、（可选）可重入/公平
数据库锁：简单但性能差，适合低并发
Redis 锁（AP）：极高性能，但不绝对可靠；Redlock 有争议
Zookeeper 锁（CP）：顺序临时节点，强一致公平锁
etcd 锁（CP）：Lease + 事务，云原生首选
本质：CP 锁可靠慢，AP 锁快但可能假成功；按业务对可靠性的要求选

下一篇讲分布式事务——跨服务/数据库如何保证一致性。

分布式系统学习笔记（二）：共识算法 Raft

Mon, 18 May 2026 10:00:00 +0800

写在前面

本文讲共识算法（Consensus）——多个节点如何对某个值达成一致。它是 CP 系统（etcd、Zookeeper、TiKV）实现强一致性的核心。重点讲 Raft（比 Paxos 好懂），它是现代分布式系统的共识算法标配。

一、什么是共识问题

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


共识（Consensus）：多个节点就某个决议（值）达成一致

典型场景：
 - 选主：哪个节点当 Leader
 - 日志复制：操作的顺序（先 A 后 B，还是先 B 后 A）
 - 状态机复制：所有副本状态一致

难点：
 节点可能宕机
 网络可能丢包/延迟/分区
 没有全局时钟

 但必须保证：
 所有正常节点达成相同决议
 决议一旦达成不可更改
 能容忍少数节点故障

二、Paxos（经典但难懂）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Paxos（Lamport 1998）是共识算法的鼻祖
 数学上严谨、正确
 但极难理解、更难实现

 核心思想：多数派（Quorum）+ 两阶段（Prepare/Accept）
 只要多数节点同意，决议通过

 实际系统很少直接用 Paxos（太复杂）
 多用 Raft（更易懂的等价算法）或 Paxos 变体
 （Doris 用 Paxos 变体、Chubby 用 Paxos、Spanner 用 Paxos）

三、Raft 核心思路

Raft（2013）的设计目标就是"好懂"。它把共识拆成三个子问题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. Leader 选举（Leader Election）
 选出一个 Leader 处理所有请求

2. 日志复制（Log Replication）
 Leader 接收请求，复制到其他节点，多数确认后提交

3. 安全性（Safety）
 保证已提交的日志不被覆盖

核心简化：把"任意节点都可提议"简化为"只有 Leader 提议"
 一切由 Leader 主导，逻辑清晰

3.1 节点状态

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


每个节点三种状态：
 Follower — 跟随者，被动接收 Leader 指令
 Candidate — 候选者，发起选举
 Leader — 领导者，处理所有请求

状态转换：
 Follower ──(超时无心跳)──→ Candidate
 Candidate ──(获多数票)──→ Leader
 Candidate ──(发现更高term的Leader)──→ Follower
 Leader ──(发现更高term)──→ Follower

四、Leader 选举

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


1. 初始都是 Follower
2. 一段时间没收到 Leader 心跳 → 超时
3. Follower 变 Candidate，term+1，给自己投票，发 RequestVote
4. 其他节点收到：
 - 如果 Candidate 日志不比自己旧 → 投票
 - 每个 term 只投一票（先到先得）
5. Candidate 收到多数票 → 成为 Leader
6. Leader 定期发心跳，维持权威

 term（任期）是 Raft 的逻辑时钟：
 单调递增
 每个 term 最多一个 Leader
 term 小的服从 term 大的

1
2
3


避免选主冲突（脑裂）：
 随机化选举超时时间（150~300ms 随机）
 避免多个节点同时超时、同时竞选

五、日志复制

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


Leader 处理客户端请求的流程：

1. 客户端发请求给 Leader（写命令）
2. Leader 写入本地日志（未提交）
3. Leader 并发发给所有 Follower（AppendEntries）
4. Follower 写入本地日志，回复 ACK
5. Leader 收到「多数」ACK → 提交（commit）
6. Leader 回复客户端「成功」
7. Leader 在下次心跳通知 Follower 提交
8. Follower 提交，状态机应用

 关键：多数（Quorum）确认才提交
 3 节点集群，2 个确认即可（容忍 1 个故障）
 5 节点集群，3 个确认即可（容忍 2 个故障）

1
2
3
4
5
6
7
8
9


Quorum 公式：
 N 个节点，多数 = ⌊N/2⌋ + 1
 可容忍故障 = N - 多数

 3 节点：多数 2，容错 1
 5 节点：多数 3，容错 2
 7 节点：多数 4，容错 3

 常用奇数节点（3/5/7），性价比高

六、安全性保证

Raft 保证几个关键不变式：

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


1. Leader 完整性
 如果一条日志在某个 term 提交了，
 那它一定存在于所有后续 term 的 Leader 日志中

2. 状态机安全
 所有节点按相同顺序应用相同日志 → 状态一致

3. 选举限制
 投票时，Follower 只投给「日志至少和自己一样新」的 Candidate
 → 保证新 Leader 不会丢已提交日志

 这些不变式保证了：已提交的数据绝不丢、所有副本最终一致

七、脑裂与 Quorum

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


脑裂（Split Brain）：网络分区导致两个 Leader

 例：5 节点分区成 3 + 2
 3 那边有多数，能选主、能提交（正常工作）
 2 那边没多数，选不出主 / 无法提交（拒绝服务）

 → Quorum（多数派）天然防止脑裂
 只有拥有多数的分区才能写入，少数分区自动失效

 这就是 CP 系统"分区时牺牲可用性"的体现

八、实际应用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


系统 共识算法 用途
──────────────────────────────────────────────
etcd Raft K8s 配置/服务发现
Consul Raft 服务发现/配置
TiKV Raft 分布式 KV（TiDB 底层）
CockroachDB Raft 分布式 SQL
Nacos Raft（自研） 配置/注册中心
Doris Paxos 变体 MPP 数据库
Zookeeper ZAB（Paxos 类） 协调服务
Spanner Paxos Google 全球数据库

1
2
3
4
5
6
7


Raft 为什么流行：
 ✓ 好懂（相比 Paxos）
 ✓ 易实现
 ✓ 工程友好（Leader 模型清晰）
 ✓ 强一致性 + 容错

 现代新系统几乎都选 Raft

九、共识 vs 一致性 vs 复制

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


容易混的三个概念：

复制（Replication）
 数据在多节点存副本（手段）
 主从复制、多主复制、无主复制

共识（Consensus）
 多节点就值/顺序达成一致（强一致复制的核心机制）
 Raft、Paxos

一致性（Consistency）
 客户端看到的数据一致性级别（结果）
 强一致、最终一致

 关系：共识算法（Raft）实现强一致的复制（手段），从而提供强一致性（结果）

十、小结

共识：多节点对决议达成一致，容忍少数故障
Paxos：鼻祖但难懂；Raft：好懂的等价算法，现代标配
Raft 三子问题：Leader 选举、日志复制、安全性
核心机制：Leader 主导 + Quorum（多数确认才提交）+ term（逻辑时钟）
容错：N 节点容忍 ⌊(N-1)/2⌋ 故障，常用 3/5/7 节点
脑裂：Quorum 天然防止，少数分区无法写入
应用：etcd/Consul/TiKV/CockroachDB 等

下一篇讲分布式锁——如何用共识系统/Redis 实现互斥。

分布式系统学习笔记（一）：CAP 与一致性

Sun, 17 May 2026 10:00:00 +0800

写在前面

本文是分布式系统系列第一篇。分布式系统的所有设计都绕不开一个理论：CAP 定理。它解释了为什么没有完美的分布式系统、为什么必须在一致性和可用性间取舍。

一、CAP 定理

1.1 三个性质

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


C — Consistency（一致性）
 所有节点在同一时刻看到相同数据
 读操作总能读到最新写入
 （严格一致性 / 线性一致性）

A — Availability（可用性）
 每个请求都能收到非错误响应（不保证是最新数据）
 系统一直可用，不拒绝服务

P — Partition tolerance（分区容忍）
 网络分区（节点间断连）时系统仍能运作
 消息丢失、延迟、节点宕机不影响整体

CAP 定理：分布式系统最多同时满足三个中的两个

1.2 为什么是三选二

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


关键认知：P（分区容忍）不是可选的！

 网络一定会分区（光纤断、交换机故障、节点宕机）
 这是物理现实，无法避免
 所以 P 必须保证

 于是真正的取舍是：C 和 A 二选一
 当分区发生时：
 选 C → 拒绝服务（保证一致性，牺牲可用性）
 选 A → 继续服务（可能返回旧数据，牺牲一致性）

 所以实际是 CP 还是 AP 之争

二、CP vs AP 系统

2.1 CP 系统（强一致性）

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


分区时优先保证一致性，可能拒绝服务

代表：
 Zookeeper — 强一致（ZAB 协议），写入需要多数节点同意
 etcd — 强一致（Raft），K8s 用它存关键配置
 HBase — 强一致
 MongoDB — 单主，强一致
 关系型数据库 — 主从复制时主写从读可能不一致，但单机内强一致

特点：
 ✓ 数据强一致，不会读到旧值
 ✗ 分区时部分请求失败（不可用）
 ✗ 性能/延迟通常更高（要协调多数节点）

2.2 AP 系统（高可用）

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


分区时优先保证可用性，允许数据暂时不一致（最终一致）

代表：
 Cassandra — 可调一致性，默认高可用
 DynamoDB — 高可用
 CouchDB — 最终一致
 Redis 集群 — 主从异步复制，故障切换可能丢少量数据（偏 AP）
 Eureka — 服务注册，AP

特点：
 ✓ 始终可用，不拒绝请求
 ✓ 性能高、延迟低（不需协调多数）
 ✗ 可能读到旧数据（最终一致）
 ✗ 需要解决冲突（Vector Clock、最后写入获胜）

1
2
3


CA 系统（没有 P）：
 单机数据库（MySQL 单机）—— 不分布式，无分区问题
 一旦分布式，P 不可选，退化成 CP 或 AP

三、BASE 理论

CAP 的 AP 取舍的实践指导：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


B — Basically Available（基本可用）
 故障时允许损失部分可用性（降级、响应慢），保证核心可用

S — Soft state（软状态）
 允许数据存在中间状态（不一致），不要求时刻强一致

E — Eventually consistent（最终一致性）
 系统保证最终数据会一致，但中间可以有窗口

 BASE = 对 AP 的工程化诠释
 大型互联网系统（电商、社交）多采用 BASE + 最终一致

四、一致性模型

一致性有强弱之分，不只是"强一致 vs 不一致"。

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


强一致性（线性一致性 Linearizability）
 所有操作有全局顺序，读总能看到最新写
 最严格，实现成本最高（CP 系统）

顺序一致性（Sequential Consistency）
 所有节点看到操作顺序一致，但不一定是实时顺序
 比线性一致弱（不要求按实时顺序）

因果一致性（Causal Consistency）
 有因果关系的操作保序，无因果的可乱序

读己之所写（Read Your Writes）
 你自己写入的数据，你自己后续一定读得到

单调读（Monotonic Reads）
 不会读到比之前更旧的数据

最终一致性（Eventual Consistency）
 停止写入后，最终所有节点一致（BASE 的核心）

1
2
3
4
5
6


强 ←────────────────────────────────────→ 弱
线性一致 顺序一致 因果一致 读己写 最终一致

 越强越易用、越难实现、性能越差
 越弱越快、越可用、但需要处理不一致
 实际系统按业务选合适的级别

五、实际系统怎么选

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


场景 推荐
──────────────────────────────────────────────────
金融账户、库存扣减 强一致（CP）— 宁可不可用也不能错
配置中心、元数据 强一致（CP）— etcd/Zookeeper
用户资料、社交动态 最终一致（AP）— 可用优先
搜索、推荐、日志 最终一致（AP）
购物车、点赞、计数 最终一致（AP）
分布式锁、选主 强一致（CP）

 核心交易 → 强一致
 社交/内容 → 最终一致
 两者结合 → 不同模块不同策略

六、常见误解

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


误解1：CAP 是"任何时候三选二"
 正解：只在「分区发生时」才二选一，平时可以既 C 又 A

误解2：AP 就是不要一致性
 正解：AP 是「最终一致」，不是不要，只是不要求时刻强一致

误解3：强一致一定比最终一致好
 正解：强一致成本高、可用性低，很多场景最终一致更合适

误解4：MySQL 是 CA（没有 P）
 正解：单机 MySQL 不涉及分区；主从/集群 MySQL 是分布式的，有分区问题

七、小结

CAP：一致性、可用性、分区容忍三选二；P 不可避免，实际是 CP vs AP
CP（Zookeeper/etcd/HBase）：强一致，分区时可能不可用
AP（Cassandra/DynamoDB/Redis 集群）：高可用，最终一致
BASE：基本可用 + 软状态 + 最终一致，AP 的工程实践
一致性模型：从线性一致到最终一致，有多个级别，按业务选
选择：核心交易强一致，社交/内容最终一致

下一篇讲共识算法 Raft——CP 系统如何达成强一致。