DDIA · 复制

💡 一句话理解

复制像课堂抄笔记: 老师 (leader) 在黑板上写, 同学们 (follower) 照抄 — 同步抄是"写一笔等你确认", 异步抄是"老师自己往下讲, 慢慢抄"; 抄写有快有慢 (复制延迟), 于是出现三种怪事: 自己刚写的字自己没看见 (读己之写)、回头看笔记发现内容"变旧了" (单调读)、同学 B 的笔记里回复排在提问前面 (一致前缀)。而无主复制像小组作业: 作业发给 n 个人, 等其中 w 个收下才算交了, 交作业时问 r 个人拿版本最新的 — 只要 w+r>n, 收作业的和发作业的必然碰面。

🧠 必知必会 必考 & 必会

replication 动机

多机保存相同副本: 就近读降低延迟、副本容错、读扩展。难点只有一个: 变更如何传播。

# 读扩展: 8 副本扛读, 1 leader 收写
# 容错: 挂 1 副本, 数据还在 (看同步/异步)
# 低延迟: 用户读就近 DC 副本

单主 / 多主 / 无主

单主: 一个 leader 接写、日志传播 — 最主流; 多主: 多节点同时接写, 冲突成常态; 无主: 客户端并行写 n 副本等 w 确认。

# 单主: PG/MySQL/Redis 主从, Kafka 单主本质
# 多主: 多 DC 各有主, 离线优先应用 (CouchDB)
# 无主: Dynamo/Cassandra/Riak, 无 failover 概念

同步 / 异步 / 半同步

同步: 等 follower 确认才返回, 不丢但慢; 异步: 不等, leader 宕机可能丢已确认写; 半同步: 一个同步 + 多个异步的折中。

# 异步丢写剧本:
# 1) 写 x=1, leader 确认
# 2) 日志还没传到 follower, leader 宕机
# 3) follower 升主 → x=0 — "已确认"的写消失了

复制日志三形式

语句日志 (传 SQL, 有不确定性函数坑)、WAL 物理日志 (耦合存储引擎版本)、逻辑日志 (行级变更, 与引擎解耦 — 可被 CDC 消费)。

# 语句日志的坑: NOW() / RAND() 各副本结果不同
# WAL: 复制必须同版本同引擎 (升级麻烦)
# 逻辑日志: {"op":"update","row":...} → Debezium

failover 三风险

leader 挂了要: 检测→选新主→重配置。三险: 新主丢写 (异步)、双主脑裂 (旧主复活)、超时判定 (慢≠死)。

# 脑裂剧本: 旧 leader 只是网络分区, 没死
# 新 leader 已选出 → 两个都接受写
# 解法: 多数派选主 + 旧主 fencing (见共识页)

最终一致性

停止写入并等待后, 副本终将一致。它是活性性质 — 只说"最终", 不说多久, 不说读到的顺序。

# "eventually" 的含糊:
#   100ms? 10min? 没人承诺
# 所以应用层要自保: 三一致性 + 幂等

三种用户可见症状

读己之写 (看不见自己的写)、单调读 (时间倒流)、一致前缀读 (因果乱序) — 各有便宜的针对性修法, 不必全库强一致。

# 读己之写: 用户数据读 leader, 其他读 follower
# 单调读:   user_id 哈希到固定副本
# 一致前缀: 因果链写同一分区

happens-before

B 知道/依赖 A ⇒ A 先于 B; 两个操作互不知晓 = 并发 — 与物理时间戳无关。判断靠版本信息, 不靠钟。

# A: 客户端1 set cart={apple}
# B: 客户端2 set cart={banana}  (基于旧值?)
# B 不知道 A → A、B 并发 → 需要合并而非覆盖

LWW 的代价

最后写入者获胜: 按时间戳取最大, 静默丢弃并发写。时钟偏移会让"慢一拍的正确数据"输给"时钟快的错误数据"。

# 节点A 时钟 +5min: cart={apple} ts=10:05
# 节点B 时钟正常:  cart={banana} ts=10:00
# LWW → banana 丢, 用户无感知 — 最危险的静默

sibling 与 CRDT

并发写并存为兄弟值 (sibling), 由客户端合并; CRDT 是"怎么合并都不冲突"的数据结构族 — 计数器/集合/序列各有算法, 保强最终一致。

# PN-Counter: 加减各一个 G-Counter, 合并取 max
counter_a = {"n1": 3, "n2": 1}
counter_b = {"n1": 2, "n2": 4}
merged = {k: max(counter_a[k], counter_b[k]) for k in ...}
# → {n1:3, n2:4} 任意顺序合并结果一致

quorum: w+r>n

n 副本写 w 读 r: 读写集合必相交, 读时取最新版本即"大概率最新"。n=3,w=2,r=2 容 1 节点故障。

n, w, r = 3, 2, 2
# 写: 等 2 个副本确认 (C 可能是旧的)
# 读: 问 3 个, 取版本最新的 2 个交集 → 见到最新写
# w+r<=n: 读可能完全错过写 — 一致性破洞

修复三件套

read repair: 读时发现旧值顺手回写; hinted handoff: 节点宕机时代收写, 恢复转交; anti-entropy: 后台定期比对副本差异补齐。

# 读 A,B (最新) + C (旧) → 顺手把 C 更新 = read repair
# C 宕机 → D 代收写并记 hint → C 回来转交
# 漏网之鱼 → 后台 anti-entropy 定期兜底

version vector

每副本每 key 的计数器集合: 比较 [A:1,B:2] 与 [A:2,B:1] — 互不压制 = 并发, 需要 sibling 合并; 完全压制 = 因果先后。

va = {"n1": 1, "n2": 0}   # n1 写过 1 次
vb = {"n1": 0, "n2": 1}   # n2 写过 1 次
# 谁也不"大于"谁 → 并发 → sibling

🏭 生产实战 real world

# 时间线还原:
# 10:00:00 写订单 x, leader 确认 (binlog 未传完)
# 10:00:00.3 leader 宕机, 提升 follower (缺 x)
# → x 永久丢失, 但用户已收到"成功"

# 修复: MySQL 半同步
-- 至少 1 个从库确认收到 binlog 才返回客户端
SET GLOBAL rpl_semi_sync_master_enabled = 1;
rpl_semi_sync_master_timeout = 1000;  -- 1s 超时降级异步

# 防护组合拳:
# 1) 选主必须多数派同意 ( minority 的"主"无效)
# 2) 旧主每次写前检查: 我还是主吗? (lease/etcd session)
# 3) 存储层 fencing: 只接受最高 epoch 的写

# MySQL 侧: Super Read Only 兜底
SET GLOBAL super_read_only = ON;  -- 疑似旧主只读
# 配合 VIP/arbitrator: 仲裁节点防止 minority 自行称主

# 修法 1: 用户自己的写后 N 秒内强制读 leader
if user.last_write_at > now() - 60s:
    read_from = leader          # 自己的资料
else:
    read_from = random_follower

# 修法 2: 记录写时间戳, follower 落后超过则换副本
def pick_follower(user_ts):
    for f in followers:
        if f.lag_behind() < user_ts_offset:
            return f            # 够新的副本
    return leader

# sticky routing: 同一用户粘同一副本
def route(user_id):
    idx = hash(user_id) % len(followers)
    return followers[idx]       # 总是同一个

# 该副本故障时: 切到 lag ≤ 原副本的节点, 而不是任意节点
# 配合: 会话粘性 (session affinity) 在网关层实现

# 根因: 帖子和回复被分到不同分区, 复制进度独立

# 修法 1: 因果相关数据同分区 (partition key 用帖子 id)
-- 帖子与其回复进同一分区, 复制顺序天然一致
PARTITION BY post_id;

# 修法 2: 全序广播 — 所有写都按同一顺序可见 (强工具, 见共识页)

-- PG: 每个从库落后多少字节
SELECT client_addr,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

-- MySQL: Seconds_Behind_Master
SHOW SLAVE STATUS LIKE 'Seconds_Behind_Master';

# 告警: lag > 30s 持续 5min → page; 写后读敏感页面降级提示

# LWW: 手机端 add(苹果) 与 Web 端 add(香蕉) 并发
# 时间戳定胜负 → 有一台的数据凭空消失

# 修复: 购物车建模为"加集 + 删集", 合并取并集
cart_add = {"apple", "banana"}     # 两端合并
cart_del = {"pear"}                # 删除也集合并集
final = cart_add - cart_del
# 每端各自合并, 结果收敛且不丢 — OR-Set (CRDT 家族)

# 推演表 (n=3):
# w=1,r=1: 最快;  挂1节点读可能全是旧值 ✗
# w=2,r=2: 挂1节点可读写, 读写必交 ✓  (推荐)
# w=3,r=3: 一致最强; 挂1节点不可写   ✗
# w=2,r=1: 写交了读没交 → 可能读旧    ✗

# 结论写进 schema 注释:
-- orders: RF=3, write CL=QUORUM, read CL=LOCAL_QUORUM

# 每设备都是一个 leader, 离线照常编辑
doc_phone = Automerge.change(doc, d => d.text = "hello world")
doc_web   = Automerge.change(doc, d => d.text = "hello CRDT")

merged = Automerge.merge(doc_phone, doc_web)
# 序列型 CRDT (RGA) 按位置标识合并 — 不靠时钟
# 任意顺序 merge 结果一致 = 收敛性保证

# 1) 读修复 (被动): 读到旧值顺手回写
rows = read_quorum(key)      # 发现 C 是旧值
write_back(node_C, latest)   # 顺手补齐

# 2) anti-entropy (主动): 定期比对 Merkel 树
#    只同步有差异的 range, 带宽省 99%
repair_job.schedule(interval="6h", rate_limit="50MB/s")

# 3) 冷数据没流量没 job → hinted handoff 兜底转交

⚠️ 编码注意与常见坑 pitfalls

# 错: 支付库 async replica + 自动 failover
# 对: semisync / group replication / Raft

# 错: VIP 漂移就完事
# 对: 写前验 lease + 只收最高 epoch

# 错: 告警叫人拔网线
# 对: minority 自动 read-only

# 错: 只监控 slave 进程存活
# 对: Seconds_Behind_Master > 30 → page

# 错: 所有读随机打副本
# 对: 写后 60s 内自己的读走 leader

# 错: 每次请求随机副本
# 对: sticky by user_id

# 错: posts 与 replies 各自哈希分区
# 对: partition by post_id (帖+回复同区)

# 错: 文档编辑 LWW
# 对: CRDT (RGA/Yjs) 逐操作合并

# 错: ts = time.time() 定胜负
# 对: Lamport/HLC 计数器优先

# 错: 同机房 2 个可写节点
# 对: 跨 DC 容灾需求再上多主

# 错: A→B→C→A 无限循环
# 对: 消息带 visited=[A,B], C 不回发

# 错: RF=2 w=1 r=1 "省资源"
# 对: RF=3 w=2 r=2 起步

# 错: w OK 就当写成功可读
# 对: UI 提示"同步中" + 后续反熵修复

# 错: "handoff 会补的" 就不管了
# 对: 恢复后强制 repair 一次

# 错: "有 read repair 就够"
# 对: 6h 一次 anti-entropy job

# 错: 整个文档状态塞 RGA
# 对: 计数器用 PN-Counter, 文本用 RGA

# 错: 每个临时设备都进 version vector
# 对: 固定副本集 + client 用独立合并通道

# 错: failover 代码三年没跑过
# 对: chaos: kill leader 每月一次

# 错: lag=1h 时强切从库
# 对: 切换前校验 lag 阈值

# 错: 50 leader 两两互联
# 对: DC 内主从 + DC 间星形