📚 课程目录第2章分布式一致性基础

分布式一致性基础

咱们做零信任网络，核心是信任不再默认，每次访问都得校验。那校验的数据——策略、会话状态、设备指纹——存在多个节点上，怎么保证它们看到的是同一份信息？这就是分布式一致性问题。说白了，就是一群机器能不能商量出一个大家都认的结果。

一致性模型定义了系统在多副本环境下，对读写操作的可见性承诺。承诺越强，系统越难做，性能代价也越大。

写操作完成后，任何后续的读操作都能立刻读到最新值。感觉就像只有一份数据一样。我在做分布式数据库选型时遇到过：金融转账场景，用户转完钱后刷新页面，余额必须马上变。否则用户会慌，客服会炸。强一致性就是干这个的。

实现手段：通常靠 Paxos 或 Raft 这类共识算法，或者用全局锁、单主复制。代价是延迟高、吞吐低。

写操作完成后，系统不保证后续读操作能读到最新值。甚至可能读到一个过期的值。为什么会有这种模型？因为有些场景对实时性要求不高，比如用户发一条朋友圈，朋友晚几秒看到也没关系。弱一致性可以换来更低的延迟和更高的可用性。

注意：弱一致性不是一个精确的术语，它通常指“不保证强一致性”的所有模型的统称。用得不好容易出事故。

这是弱一致性里最常用的一种。系统保证：如果没有新的更新操作，经过一段时间后，所有副本最终都会达到一致。我做过一个 CDN 缓存刷新项目：用户修改了网站 logo，后台把旧缓存标记失效，各地缓存节点分批拉取新图片。几秒到几分钟内，所有用户看到的都是新 logo。这就是最终一致性的典型应用。

衡量指标：最终一致性的核心是“不一致时间窗口”。窗口越短，用户体验越好。你可以通过 gossip 协议、版本向量等技术加速收敛。

下面这个表格可以帮你快速对比这三种模型：

模型	读写可见性	典型场景	性能代价
强一致性	写后立即读得到最新值	金融、分布式锁	高（延迟大、吞吐低）
弱一致性	不保证读到最新	日志、监控指标	低
最终一致性	副本最终收敛到相同值	DNS、CDN、社交动态	中（取决于收敛速度）

CAP 定理是 Eric Brewer 在 2000 年提出的，后来被证明。它说：分布式系统在 C（一致性）、A（可用性）、P（分区容错性） 三者中，最多只能同时满足两个。

我个人习惯把 CAP 理解为：网络分区是必然发生的，所以你必须先选 P（分区容忍）。然后你只能在 C 和 A 之间二选一。你想想看，分区发生后，系统内部互相连不上，如果坚持 C，就必须拒绝请求（降低 A）；如果坚持 A，就只能返回旧数据（放弃 C）。

经典分类：

我曾经踩过一个坑：一个微服务网关，为了强一致性引入了乐观锁，结果高并发时大量请求被拒绝，用户看到 503。后来改成最终一致性 + 补偿机制，系统才稳下来。嗯，CAP 不是让你选一个放弃另一个，而是让你在设计和运行时做 trade-off。

BASE 是 Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）的缩写。它是 Dan Pritchett 在 2008 年提出的，专门针对大型高可用分布式系统。

维度	解释	我见过的例子
基本可用	系统允许部分功能降级，但核心功能保持可用。比如双十一的“挤眉弄眼”排队页面。	我们做过一个支付系统，DB 扛不住时，先让用户看到“支付中”状态，事后异步对账。
软状态	系统中数据状态可以有一段时间不一致，不要求实时同步。	用户修改密码后，旧在 5 分钟内依然有效，这属于软状态。
最终一致性	没有新写入后，系统最终会达到一致。	零信任策略下发：策略变更后，各 PDP（策略决策点）慢慢拉取最新策略，最终同步。

建议：零信任网络里，策略分发、会话同步最适合用 BASE。你不可能让每个策略变更都同步阻塞所有请求，那系统就瘫了。但审计日志和权限变更记录必须强一致，否则有人利用时间差越权。

下面是本章的核心知识结构图，帮你把这三块内容串起来。

我个人觉得，零信任网络里没有银弹。不同层级、不同数据该用哪种一致性模型，得结合业务场景定。比如用户登录 session 可以用最终一致性，但权限变更日志必须强一致——不然有人被踢出后又偷偷溜回来。这种取舍，就是 CAP 和 BASE 教我们的核心能力。