第二大脑

主题

2026-08-24
767
2.8m

概念卡片：分布式一致性理论 ​

一句话机制：分布式系统的地基是 CAP 定理——一致性 C、可用性 A、分区容错 P 三者不可兼得；P 必然存在，只能在 A 和 C 之间二选一，由此衍生出追求强一致的 CP 路线（ACID + 共识算法）和追求高可用的 AP 路线（BASE + 最终一致）。

CAP 定理 ​

维度含义
C 一致性任意节点读到的是同一份最新数据（或读失败）
A 可用性请求总能在有限时间返回结果
P 分区容错节点间消息丢失/延迟/分区时仍能服务

P 必须满足（网络交互必有延迟和丢包）→ 分区故障时只能在 A、C 之间选一个。

CAP 三模型与实现 ​

模型取舍典型实现
CA舍 P（= 单机）单机 MySQL—
CP舍 A（强一致，弱可用）Zookeeper/Etcd/HBaseRaft / ZAB
AP舍 C（高可用，最终一致）Cassandra/DynamoDBQuorum NWR / Gossip

ACID 与 BASE（CAP 的两个延伸） ​

ACIDBASE
来源CAP 的 CP 延伸CAP 的 AP 延伸
追求强一致（最强）基本可用 + 软状态 + 最终一致
落地2PC / 3PC / TCC / 消息补偿读时修复 / 写时修复 / 异步修复

共识算法（CP 的核心） ​

算法说明
Paxos一致性共识的鼻祖，难理解难实现
RaftPaxos 的简化版，靠「Leader + 日志复制 + 选举」，工程界主流
ZABZookeeper 专用，二阶段提交 + 崩溃恢复，靠 ZXID 保证顺序

一致性哈希（数据分布） ​

把节点和数据都哈希到同一个「环」上，数据落到顺时针最近的节点；加/减节点只影响相邻一段数据，避免传统取模哈希的大规模数据迁移。

不变量（必须成立的约束） ​

  • CAP 不是三选一，是「P 必选，A/C 二选一」——很多场景误以为能三者兼得。
  • 强一致（CP）代价是弱可用，最终一致（AP）代价是短暂不一致，按业务选。
  • 共识算法（Raft/ZAB）解决「多副本如何达成一致」，一致性哈希解决「数据如何分布到多节点」。

踩坑案例 ​

  • 现象：把 Zookeeper 当「强一致 + 高可用」都满足的注册中心，结果网络分区时发现它牺牲了可用性。 原因：Zookeeper 是 CP（ZAB 保证强一致），分区时会拒绝写入。解决：注册场景要「可用性优先」就选 AP 的 Nacos/Eureka。

常见误解 ​

  • 以为 CAP 能三者兼得 → P 必然存在，只能 A/C 二选一。
  • 以为「最终一致」是「不一致」→ 它是在「软状态」窗口后收敛到一致，是 AP 路线下的合理折中。

关联 ​

最近更新