📚 课程目录第3章一致性模型

一致性模型对比：强一致性、最终一致性、读写一致性、因果一致性

在分布式缓存系统中，一致性模型定义了数据在多个副本之间同步的可见性规则。选择合适的一致性模型是缓存治理的核心决策，直接影响系统的正确性、可用性和性能。本章对四种主流一致性模型进行系统性对比，帮助你在不同业务场景下做出合理选择。

  核心原则：一致性模型的选择本质是在“数据正确性”与“系统可用性/性能”之间做权衡。没有一种模型适用于所有场景，必须结合业务容忍度进行契约化治理。

1. 一致性模型全景对比

下表从定义、核心保证、典型实现、性能影响和适用场景五个维度，对四种模型进行横向对比：

模型	核心保证	典型实现	性能影响	适用场景
强一致性	所有读操作都能读到最新写入的值	Paxos / Raft 共识算法、同步复制	高延迟、低吞吐（需多数派确认）	金融交易、库存扣减、分布式锁
最终一致性	如果没有新写入，所有副本最终会达到一致状态	异步复制、Gossip 协议、DNS	低延迟、高吞吐、弱实时保证	社交动态、CDN 缓存、日志收集
读写一致性	写后立即读自己的写（Read-Your-Writes）	Session 级一致性、粘性连接	中等延迟（需路由到主副本）	用户个人设置、购物车、会话数据
因果一致性	有因果关系的操作按顺序被所有节点看到	向量时钟、版本向量、CRDT	中等延迟（需维护因果依赖元数据）	协作编辑、评论系统、消息排序

2. 强一致性（Strong Consistency）

强一致性要求系统对外表现为一个单副本系统。任何时刻，所有节点对同一数据的值认知完全一致。写入操作必须等待所有副本（或多数派）确认后才返回成功，读取操作必须从已同步的副本获取数据。

治理陷阱：强一致性在分布式环境下会显著降低可用性（CAP 定理中的 CP 倾向）。当网络分区发生时，系统可能拒绝写入以维持一致性，导致部分服务不可用。在缓存场景中，强一致性通常只用于元数据或关键状态，不适用于高频缓存数据。

典型实现路径：

共识算法：使用 Raft 或 Paxos 确保写入被多数派接受后才提交。
同步复制：主库等待所有从库确认写入完成后再响应客户端。
分布式事务：通过 2PC/3PC 协议协调多个节点的写入操作。

// 强一致性写入伪代码（Raft 风格）
func Write(key string, value interface{}) error {
    // 1. 将写入请求追加到本地日志
    entry := LogEntry{Key: key, Value: value, Term: currentTerm}
    log.Append(entry)
    
    // 2. 并行发送 AppendEntries RPC 到所有从节点
    successCount := 1  // 包含自己
    for _, peer := range peers {
        go func(p Peer) {
            if p.AppendEntries(entry) == OK {
                successCount++
            }
        }(peer)
    }
    
    // 3. 等待多数派确认（超时机制）
    if successCount > len(peers)/2 {
        applyToStateMachine(entry)
        return nil
    }
    return ErrConsensusTimeout
}

3. 最终一致性（Eventual Consistency）

最终一致性是分布式系统中最宽松的模型。它保证如果没有新的写入操作，所有副本最终会达到一致状态，但不保证具体的时间窗口。在达到一致之前，不同副本可能返回不同的值。

关键特征：

无实时保证：系统不承诺在多长时间内达成一致，只保证“最终”会一致。
高可用性：写入操作只需在单个节点上完成即可返回，无需等待其他副本确认。
冲突风险：并发写入可能导致数据冲突，需要冲突解决策略（如 LWW、CRDT）。

实践建议：在缓存治理中，最终一致性适用于对实时性要求不高的场景。例如，用户头像缓存、热门文章列表等。建议配合 TTL 过期机制，确保数据在可接受的时间窗口内收敛。

4. 读写一致性（Read-Your-Writes Consistency）

读写一致性（又称写后读一致性）保证：客户端在写入数据后，立即发起的读操作一定能看到自己刚刚写入的值。这是最终一致性的增强版本，它解决了“自己写的数据自己看不到”的问题。

实现策略：

策略	实现方式	优点	缺点
粘性连接	将客户端绑定到写入的主副本，后续读请求路由到同一副本	实现简单，无需额外元数据	负载不均衡，主副本故障时失效
时间戳标记	写入时返回时间戳，读请求携带该时间戳，只返回 >= 该时间戳的数据	支持副本切换，灵活性高	需要时钟同步，增加元数据开销
版本向量	维护每个客户端的写入版本号，读请求检查版本号是否满足	精确控制，不依赖时钟	版本管理复杂，存储开销大

// 读写一致性实现：基于 Session 的粘性路由
type SessionAwareCache struct {
    sessionTable map[string]string  // sessionID -> primaryNode
    primaryNode  string
}

func (c *SessionAwareCache) Write(sessionID, key, value string) error {
    // 记录当前 session 的主节点
    c.sessionTable[sessionID] = c.primaryNode
    // 写入主节点
    return c.writeToNode(c.primaryNode, key, value)
}

func (c *SessionAwareCache) Read(sessionID, key string) (string, error) {
    // 优先从 session 绑定的主节点读取
    if node, ok := c.sessionTable[sessionID]; ok {
        return c.readFromNode(node, key)
    }
    // 无绑定关系时从任意副本读取
    return c.readFromNode(c.primaryNode, key)
}

5. 因果一致性（Causal Consistency）

因果一致性是介于强一致性和最终一致性之间的模型。它只保证有因果关系的操作按正确的顺序被所有节点观察到，而并发无关的操作可以任意排序。因果关系通常由“发生在之前”（happens-before）关系定义。

核心概念：

因果依赖：操作 A 的结果被操作 B 使用，则 A 发生在 B 之前。
并发操作：两个操作之间没有因果依赖关系，可以任意排序。
向量时钟：每个节点维护一个向量 (v1, v2, ..., vn)，记录每个节点的逻辑时钟值，用于判断因果关系。

  典型场景：在社交评论系统中，用户 A 发表评论（操作1），用户 B 回复该评论（操作2）。操作2 因果依赖于操作1，因此所有用户必须先看到操作1，再看到操作2。而用户 C 同时发表的另一条评论（操作3）与操作1/2 无因果关系，可以任意顺序展示。

6. 模型选择决策矩阵

在实际的缓存治理项目中，需要根据业务需求、性能目标和运维成本综合选择一致性模型。以下决策矩阵可以帮助你快速定位：

业务需求	推荐模型	理由	缓存示例
金融交易、库存扣减	强一致性	数据错误会导致直接经济损失，必须保证绝对一致	Redis RedLock、Etcd 分布式锁
用户个人设置、购物车	读写一致性	用户期望立即看到自己的操作结果，但不关心其他用户	Session 级缓存、粘性 Redis 连接
社交动态、新闻 feed	因果一致性	需要保证评论/回复的顺序正确，但允许一定延迟	CRDT 同步、向量时钟缓存
CDN 缓存、静态资源	最终一致性	高并发场景，允许短暂的不一致，TTL 过期后自动收敛	Redis 异步复制、Memcached 集群
实时排行榜、计数器	最终一致性 + 读写一致性	写操作频繁，读操作要求看到最新值但不要求全局一致	Redis 主从 + 读写分离

治理契约要点：在项目部署前，必须通过契约测试明确声明每个缓存键（Cache Key）所使用的一致性模型。例如：user:profile:{uid} 使用读写一致性，news:hotlist 使用最终一致性。契约中还应包含不一致容忍时间窗口（如最终一致性允许 5 秒内收敛），作为后续测试和监控的基准。

7. 一致性模型与 CAP 定理的关系

CAP 定理指出，分布式系统在一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）三者中最多只能同时满足两个。不同一致性模型在 CAP 空间中的位置如下：

强一致性 → CP 系统：优先保证一致性，在分区时牺牲可用性（如 Zookeeper、Etcd）。
最终一致性 → AP 系统：优先保证可用性，在分区时牺牲一致性（如 Cassandra、DynamoDB）。
读写一致性 / 因果一致性 → 混合模型：在 CP 和 AP 之间取得平衡，通过客户端感知的局部一致性来提升用户体验。

在缓存治理实践中，建议采用“分级治理”策略：将缓存数据按一致性要求分为不同等级，每个等级使用不同的模型和部署架构。例如，L0 级（强一致）使用 Raft 集群，L1 级（读写一致）使用主从复制，L2 级（最终一致）使用异步 Gossip 同步。