CockroachDB：多活与Serializable隔离

可视化演示

展示CockroachDB的Raft共识副本一致性、Serializable隔离级别事务排序及跨区域Leaseholder就近延迟优化，交互切换理解分布式强一致性。

多活架构

假设你的咖啡馆扩张到了 30 个城市。传统做法是“总部定菜谱，分店只能照做”：所有会员卡数据只存在总部机房，分店每天要把账本传回去。一旦总部停电，全世界的分店都无法验证会员余额。这就是典型的“主从单活”架构——只有一个写入口，主库挂了，业务就停摆。而多活（Multi-Active）的思路是：每家分店都是一家独立运作的“总部”，都能收银、充值、盘点库存。

CockroachDB 正是这种“处处皆总部”的设计。集群中每个节点都完全对等，任意节点都能接收读写请求，不存在“主库优先”的单点瓶颈。相较于主从架构中故障切换需要人工或脚本提升新主、产生秒级不可用窗口，多活架构中其他节点天然在线，请求自动绕开故障节点，切换过程对客户端几乎无感。

多活的收益可以用一个概率公式直观展示。假设单个区域的数据中心可用性为 a，部署了 n 个多活区域，则整体可用性为：

$$A = 1 - (1-a)^{n}$$

1. 区域可用性 a：a 表示单个数据中心在单位时间内正常运行的概率，比如 0.99（99%）。

$$a = \dfrac{\text{正常时间}}{\text{正常时间} + \text{故障时间}}$$

2. 单区域不可用：某个区域发生故障的概率为 1 - a。

$$1-a$$

3. 全部区域同时故障：假设区域故障互相独立，n 个区域全挂的概率是 (1 - a) 的 n 次方。

$$(1-a)^n$$

4. 至少一个区域存活：用 1 减去“全挂”的概率，就是多活集群的整体可用性。

$$A = 1 - (1-a)^n$$

回看咖啡馆：每家分店都独立运作，30 家分店同时关门的概率趋近于零。多活架构没有“总部”这一致命单点，这正是它能在全球范围持续营业的根本原因。

地理复制

你决定把会员数据印成五本《全球会员总账》，分别锁在上海、北京、广州、成都、深圳五个城市的分店保险柜里。顾客在任何一家分店充值，店员必须当场打电话向其他分店确认——通了至少三家，这笔充值才生效。这就是地理复制：数据副本分散在不同地理区域，相互备份并协同服务。

CockroachDB 中，一个 range（数据分片）默认保存多个副本（replica），并可通过配置把副本分布到不同的 region（区域）和 availability zone（可用区）。每个区域是独立的故障域，电力、网络、制冷都独立。跨区域分布让“一个机房着火烧掉账本”变成小概率事件：只要多数派副本存活，数据就完好无损。

副本数 R 决定了系统能容忍的故障数。由于写入需要多数派副本确认，容错上限为：

$$f_{\max} = \left\lfloor \dfrac{R-1}{2} \right\rfloor$$

1. 多数派写：R 个副本中超过一半（≥ ⌊R/2⌋+1）确认，写入才算成功。

$$\text{需要确认数} = \left\lfloor \dfrac{R}{2} \right\rfloor + 1$$

2. 可容忍故障数：只要故障副本数不超过“R 减去多数派阈值”，多数派就仍然存在。

$$R - \left(\left\lfloor \dfrac{R}{2} \right\rfloor + 1\right) = \left\lfloor \dfrac{R-1}{2} \right\rfloor$$

3. 五副本实例：R=5 时，需要 3 个副本确认，最多可容忍 2 个副本同时故障。

$$f_{\max} = \left\lfloor \dfrac{5-1}{2} \right\rfloor = 2$$

五本账本放在五个城市，烧掉任意两家分店，剩下三本账仍然多数一致。地理复制为“多活”提供了数据层面的地基——副本存得越分散，局部灾难对全局的影响就越小。

Raft共识

店长们定下一条规矩：任何跨店账目变更，必须由当周轮值主席（Leader）发起，至少三位店长在对讲机里表示“收到且同意”，才能写进各自账本。主席每隔几秒要喊一次“我还活着”（心跳），大家发现主席失联，就重新投票选新主席。这套店长议事规则，正是分布式系统里鼎鼎大名的 Raft 共识算法。

Raft 把复杂的共识问题拆成三个子问题：领导者选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。所有写请求先到达 Leader，Leader 把操作追加进自己的日志，然后广播给各副本；各副本追加日志后回复“已记录”；Leader 收到多数派确认后，才把这条日志标记为已提交（committed），并通知客户端成功。读请求由 Leader 或拥有最新租约的副本处理，保证读到的数据不落后。

多数派阈值是 Raft 的灵魂。假设集群有 n 个节点，需要超过半数的节点确认才能提交：

$$Q = \left\lfloor \dfrac{n}{2} \right\rfloor + 1$$

1. 节点总数 n：参与 Raft 表决的副本节点数量。

$$n$$

2. 多数派阈值 Q：大于 n/2 的最小整数，即至少需要 Q 个节点确认。

$$Q = \left\lfloor \dfrac{n}{2} \right\rfloor + 1$$

3. 交集必然性：任意两组 Q 个节点，它们的交集非空，因为 2Q > n。

$$2Q = 2\left\lfloor \dfrac{n}{2} \right\rfloor + 2 > n$$

对讲机规矩看起来很笨——每笔账都要喊一圈。但正是这条“少数服从多数”的规矩，让 30 家分店在主席失联、网络抖动时依然能选出新主席，继续营业。Raft 是多活集群的“神经系统”。

可串行化隔离

周末限定咖啡只剩最后一杯。顾客甲正扫码付款，顾客乙也同时发起购买。两人都可能在屏幕前认为自己“锁定了这杯咖啡”。为了避免超卖和误解，你规定：如果两位顾客的操作没形成“循环等待”，就按先完成付款的人得手；一旦发现“你等我取消、我等你取消”的僵局，强制中止后到的那一位，请 TA 稍后再试。这个裁决哲学，就是 Serializable（可串行化）隔离。

数据库隔离级别从低到高有：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）、可串行化（Serializable）。最高级别的可串行化意味着：多个并发事务执行后的结果，等价于它们按某个顺序一个一个执行的结果。CockroachDB 默认实现了可串行化快照隔离（SSI，Serializable Snapshot Isolation）。SSI 不是悲观地给每一行加锁排队，而是让事务乐观地并发执行，在提交时检查“读写冲突图”是否存在环。

冲突图（Conflict Graph）的节点是各事务，边代表数据访问冲突（如 T1 写了 x，T2 又读了 x）。可串行化的充要条件是冲突图无环：

$$\text{可串行化} \iff \text{冲突图无有向环}$$

1. 冲突边：若事务 T1 写入数据 x，事务 T2 之后读写 x，则画一条从 T1 指向 T2 的有向边。

$$T_1 \to T_2 \quad (\text{if } T_1 \text{ writes } x \text{ before } T_2 \text{ accesses } x)$$

2. 环检测：在冲突图上搜索有向环。若无环，则这些事务可以按拓扑序串行执行。

$$\exists\, \text{cycle} \iff \text{不可串行化}$$

3. 中止策略：发现环后，中止创建时间戳较晚（后到）的事务，让先到者正常提交。

$$\text{abort}(T_{\text{later}})$$

回到咖啡店：裁决员不需要让所有顾客排队买咖啡（那样太慢），只需要在结账瞬间检查是否有“互相卡住”的循环依赖。多数时候大家各买各的，相安无事；真有冲突时，礼貌地请后来者稍等再试。SSI 就这样在并发度与一致性之间取得了优雅的平衡。

事务处理

顾客点了一杯拿铁、一块芝士蛋糕，还办了张新会员卡。这三件事分属三家分店的库存和会员系统：咖啡豆在上海仓库、蛋糕在北京中央厨房、会员卡在广州总部。你的要求是“要么全部成功，要么全部失败”——绝不能出现“卡办了、蛋糕没出库”的尴尬。这就是事务的原子性（Atomicity）在分布式场景下的挑战。

CockroachDB 的事务可以跨任意多个 key、跨多个 range、跨多个区域。它通过“事务记录 + Raft 日志”实现原子提交：事务先在一个协调节点上写入事务记录（transaction record），各参与分片通过 Raft 完成本地写入；最终提交时，协调节点把事务记录标记为 COMMITTED，各分片异步完成清理。CockroachDB 还引入了“事务流水线”（write pipeline）和“并行提交”（parallel commits），把一次跨区域提交从多次串行网络往返压缩为并行发送，大幅降低延迟。

一次跨区域事务的总体延迟可以用简单模型表示：

$$L = 2 \times \text{RTT}_{\text{quorum}} + L_{\text{process}}$$

1. 多数派往返 RTT：从协调节点发出请求到获得多数派副本确认，需要一次网络往返。

$$\text{RTT}_{\text{quorum}} = \max_{\text{多数派}} (\text{往返时延})$$

2. 两次往返：准备阶段一次往返，最终提交确认再一次往返。

$$L_{\text{net}} = 2 \times \text{RTT}_{\text{quorum}}$$

3. 加入处理时间：加上本地 CPU、磁盘写入等处理开销，得到总延迟。

$$L = 2 \times \text{RTT}_{\text{quorum}} + L_{\text{process}}$$

广岛的三家分店通过流水线机制并行协调，不必等一家完成再去下一家；一旦其中任何一家无法完成，整笔订单回滚，顾客的钱原路退回。强一致的全局事务，让顾客永远不用担心“钱付了，咖啡没到手”。

延迟优化

常客张女士住在广州，她的会员卡数据副本恰好有一份落在广州分店。她结账时，广州店员直接查本地账本完成扣款，不需要拨长途电话问上海总部——这就叫数据局部性（data locality）：数据副本放在离用户近的地方，读写优先走本地。全球多活不等于所有请求都要绕地球一圈。

CockroachDB 的延迟优化三板斧：第一，区域感知路由（region-aware routing），客户端把请求发给最近区域的节点；第二，租约（lease）跟随数据，每个 range 的读写租约尽量分配给与客户端同区域的副本，让写请求的多数派确认也能在区域内完成；第三，Follower 读（follower reads），在保证可串行化的前提下，读请求可直接发往本地 follower 副本，用时间戳验证数据新鲜度，不必绕道 Leader。

整体期望延迟可以这样估算：

$$E[L] = p_{\text{local}} \cdot L_{\text{local}} + (1-p_{\text{local}}) \cdot L_{\text{remote}}$$

1. 本地命中率 p_local：请求在用户所在区域即可完成读写的概率。

$$p_{\text{local}} = \dfrac{\text{本地完成请求数}}{\text{总请求数}}$$

2. 本地延迟 L_local：区域内机房往返延迟，通常 1–10ms。

$$L_{\text{local}}$$

3. 远程延迟 L_remote：跨区域（如上海到广州）往返延迟，通常 30–100ms。

$$L_{\text{remote}}$$

4. 加权期望：两种延迟按命中率加权平均。

$$E[L] = p_{\text{local}} \cdot L_{\text{local}} + (1-p_{\text{local}}) \cdot L_{\text{remote}}$$

张女士的每一次点单都在广州本地秒级完成，而她的数据仍会通过 Raft 悄悄同步到其他城市——下次她去上海出差，上海店也能查到她的余额。把数据放到顾客身边，把同步放到后台，这就是多活数据库既强一致又好用的秘密。

部署实践

开店手册最后几页定下了全球布局：五个城市各存一份账本（三区域五副本），任何三份账本在线就能营业；每个季度演练一次“关闭深圳分店”，检验其他分店能否无缝接管；同时安排品控员每日抽查各地账本是否一致。这套方法论，映射到 CockroachDB 就是生产环境的标准部署实践。

典型的高可用部署是“三区域五副本”：数据按 range 切分，每个 range 的 5 个副本分布到 3 个区域（region），其中 2 个区域各放 2 个副本，第 3 个区域放 1 个副本。这样即使整个区域故障（最多损失 2 个副本），剩余 3 个副本仍构成多数派，集群继续提供读写服务：

$$Q = \left\lfloor \dfrac{5}{2} \right\rfloor + 1 = 3$$

1. 五副本分布：5 个副本按 2-2-1 布局到三个区域。

$$R = 5,\quad \text{区域}=3,\quad \text{分布}=2:2:1$$

2. 多数派阈值：5 副本需要 3 副本确认。

$$Q = \lfloor 5/2 \rfloor + 1 = 3$$

3. 容灾判定：单区域最多损失 2 副本，剩余 3 ≥ 3，故可用。

$$\text{存活}=5-2=3 = Q \Rightarrow \text{可用}$$

部署之外，还要做区域容灾演练（定期 kill 一个区域进程验证自动恢复）和一致性核查（对比各副本数据）。把开店手册变成可执行的监控、告警和演练脚本，多活集群才能真正做到“计划内从容，计划外不慌”。

AI 应用场景

Python 演示

"""简化版 SSI 冲突图环检测模拟器"""from collections import defaultdict class Txn:    def __init__(self, tid, read_keys, write_keys):        self.tid = tid        self.read_keys = set(read_keys)        self.write_keys = set(write_keys) class ConflictDetector:    def __init__(self, txns):        self.txns = txns        self.graph = defaultdict(list)        self.state = [0] * len(txns)     def add_conflict_edges(self):        for i, ti in enumerate(self.txns):            for j, tj in enumerate(self.txns):                if i == j:                    continue                if ti.write_keys & tj.read_keys:                    self.graph[i].append(j)                if ti.write_keys & tj.write_keys:                    self.graph[i].append(j)     def dfs(self, u):        self.state[u] = 1        for v in self.graph[u]:            if self.state[v] == 1:                return True            if self.state[v] == 0 and self.dfs(v):                return True        self.state[u] = 2        return False     def has_cycle(self):        for i in range(len(self.txns)):            if self.state[i] == 0 and self.dfs(i):                return True        return False def main():    txns = [        Txn(0, ["x"], ["x", "y"]),        Txn(1, ["y"], ["y", "z"]),        Txn(2, ["z"], ["x", "z"]),    ]    detector = ConflictDetector(txns)    detector.add_conflict_edges()    for i in range(len(txns)):        print("T%d 读集: %s 写集: %s" % (            i, txns[i].read_keys, txns[i].write_keys))    if detector.has_cycle():        print("检测到冲突环 -> 必须中止后到事务，保证可串行化")    else:        print("无冲突环 -> 所有事务可提交，结果可串行化") if __name__ == "__main__":    main()

1. class ConflictDetector:定义冲突检测器，负责构建冲突图并执行 DFS 环检测，对应 CockroachDB SSI 中的提交前检查。
2. def add_conflict_edges(self):遍历所有事务对，根据读写集合交集构建有向边，模拟 SSI 对数据访问冲突的收集。
3. common = ti.write_keys & tj.read_keys若事务 ti 写入的 key 被 tj 读取，构成一条读写冲突边 ti→tj，这就是冲突图的基本单元。
4. self.graph[i].append(j)把检测到的冲突边加入邻接表，形成有向图结构。
5. def dfs(self, u):深度优先搜索遍历冲突图，state[u]=1 表示当前路径上正在访问的节点。
6. if self.state[v] == 1:如果遇到正在访问的节点，说明发现后向边，即冲突环。
7. detector.add_conflict_edges()调用建图方法，把三个模拟事务的冲突关系组织成图。
8. if detector.has_cycle():检测结果决定是否中止事务，模拟 CockroachDB 提交时中止后到事务的决策。

常见误区

面试题