#一致性级别对比矩阵

学完了线性一致性、顺序一致性、因果一致性、最终一致性，以及介于最终一致性和强一致性之间的单调保证，现在来做一次横向对比。

分布式系统的一致性不是一个二元问题，而是一个从强到弱的光谱。理解这个光谱的全貌，才能在系统设计时做出明智的权衡。

#一致性光谱总览

flowchart LR
    subgraph "一致性光谱（从强到弱）"
        ST["严格一致性"]
        LIN["线性一致性"]
        SEQ["顺序一致性"]
        CAU["因果一致性"]
        MR["单调读/读你所写"]
        EC["最终一致性"]
    end

    ST --> LIN --> SEQ --> CAU --> MR --> EC

    style ST fill:#ff6b6b
    style LIN fill:#ffa94d
    style SEQ fill:#ffd43b
    style CAU fill:#69db7c
    style MR fill:#38d9a9
    style EC fill:#20c997

每一级都比上一级更弱，但也更容易实现、性能更高。

#完整对比表

#各维度详细说明

全局顺序：所有操作是否必须有一个统一的全局顺序？

• 严格一致性/线性一致性/顺序一致性：必须
• 因果一致性：必须有，但只针对有因果关系的操作
• 单调保证/最终一致性：不必须

实时序：是否要求「先完成」的操作排在「后开始」的操作前面？

• 严格一致性/线性一致性：必须
• 顺序一致性/因果一致性/单调保证/最终一致性：不必须

因果保证：是否保证「如果 A 导致 B，则 A 必须排在 B 前面」？

• 强一致性（严格/线性/顺序）：是（因为它们更强）
• 因果一致性：是（这是它的核心保证）
• 单调读/读你所写：部分（只保证会话内的因果）
• 最终一致性：否

#延迟与一致性权衡

一致性和延迟的关系可以这样理解：

graph LR
    subgraph "延迟"
        H["高延迟"] --> L["低延迟"]
    end

    subgraph "一致性"
        S["强一致"] --> W["弱一致"]
    end

    H <--> S
    L <--> W

这个关系不是绝对的，但大致成立。原因在于：

1. 强一致性需要协调：跨节点同步、共识协议、心跳保活，这些都会增加延迟
2. 弱一致性允许本地操作：写操作可以立即返回，读操作可以从本地副本返回

#量化对比

以下数据来自公开基准测试和论文（仅供参考，实际数值因场景而异）：

#选型决策树

面对具体的业务场景，如何选择合适的一致性级别？

flowchart TD
    Start["开始选型"] --> Q1{业务能接受<br/>短暂不一致吗?}

    Q1 -->|否| Q2{需要分布式锁<br/>或 Leader 选举吗?}
    Q2 -->|是| A1["选择线性一致性<br/>etcd / ZooKeeper"]
    Q2 -->|否| Q3{需要全局顺序吗?}

    Q3 -->|是| A2["选择顺序一致性<br/>单 Writer 架构"]
    Q3 -->|否| Q4{需要因果保证吗?}

    Q4 -->|是| A3["选择因果一致性<br/>Cassandra 开启后 / 向量时钟"]
    Q4 -->|否| Q5{需要单调保证吗?}

    Q5 -->|是| A4["选择单调读/读你所写<br/>会话标记"]
    Q5 -->|否| A5["选择最终一致性<br/>DynamoDB / Cassandra 默认"]

    Q1 -->|是| Q5

    style A1 fill:#ff6b6b
    style A2 fill:#ffa94d
    style A3 fill:#ffd43b
    style A4 fill:#69db7c
    style A5 fill:#20c997

#决策要点详解

问题 1：业务能接受短暂不一致吗？

如果不能（如金融交易、库存扣减），跳过剩余问题，直接考虑强一致性方案。

如果能（如社交动态、配置缓存），继续问题 2。

问题 2：需要分布式锁或 Leader 选举吗？

如果是，必须选择线性一致性。因为分布式锁依赖实时序。

如果否，继续问题 3。

问题 3：需要全局顺序吗？

如果是（如消息队列的分区顺序），选择顺序一致性。

如果否，继续问题 4。

问题 4：需要因果保证吗？

如果是（如协作编辑、评论排序），选择因果一致性。

如果否，继续问题 5。

问题 5：需要单调保证吗？

如果是（如展示用户状态、购物车），选择单调读/读你所写。

如果否，选择最终一致性。

#场景选型表

#CAP 定理再理解

CAP 定理指出：在分区（Partition）发生时，必须在一致性（Consistency）和可用性（Availability）之间权衡。

flowchart TD
    subgraph "CAP三角"
        C["一致性<br/>Consistency"]
        A["可用性<br/>Availability"]
        P["分区容错<br/>Partition Tolerance"]
    end

    C --- P
    C --- A
    P --- A

    style C fill:#ff6b6b
    style A fill:#69db7c
    style P fill:#ffd43b

但 CAP 定理常被误解。关键在于：CAP 不是三选二，而是「分区时二选一」。

重要澄清：CAP 的 C 是指「线性一致性或等价的一致性」，不是「最终一致性」。

• CP 系统：etcd、ZooKeeper、HBase（分区时可能不可用）
• AP 系统：DynamoDB、Cassandra、Riak（分区时永远可用，但可能返回旧数据）

#现实中的混合模式

现代分布式系统通常不只使用一种一致性级别，而是在不同模块使用不同级别：

#DynamoDB 的例子

DynamoDB 提供了多种一致性模式：

// DynamoDB Java SDK：不同一致性级别的读写
DynamoDB dynamoDB = new DynamoDB(dbClient);
Table table = dynamoDB.getTable("Orders");

// 最终一致性读（默认）
Item item1 = table.getItem("pk", "order-1");

// 强一致性读
GetItemSpec spec = new GetItemSpec()
    .withPrimaryKey("pk", "order-1")
    .withConsistentRead(true);
Item item2 = table.getItem(spec);

// 事务写入（强一致）
TransactWriteItemsSpec transactSpec = new TransactWriteItemsSpec()
    .withTransactItems(
        new TransactWriteItem()
            .withPut(new Put()
                .withItem(new Item()
                    .withString("pk", "order-1")
                    .withString("status", "paid")
                )
            )
    );
table.transactWriteItems(transactSpec);

#Cassandra 的例子

Cassandra 默认是最终一致性，但可以通过配置开启更强的保证：

// Cassandra Java 驱动：不同一致性级别
Session session = cluster.connect("mykeyspace");

// 最终一致性读（最低延迟）
session.execute(
    "SELECT * FROM users WHERE id = ?",
    ConsistencyLevel.ONE,
    "user-1"
);

// 单调读（需要 QUORUM）
session.execute(
    "SELECT * FROM users WHERE id = ?",
    ConsistencyLevel.QUORUM,
    "user-1"
);

// 因果一致性（需要 SERIAL）
session.execute(
    "INSERT INTO users (id, name) VALUES (?, ?)",
    ConsistencyLevel.SERIAL,
    "user-1",
    "张三"
);

#面试总结

如果你是面试官，问到分布式一致性相关的问题，通常期望你掌握以下几点：

#1. CAP 定理的准确理解

CAP 不是三选二。分区时，必须在一致性和可用性之间选择。没有分区时，两者都可以保证。

#2. 一致性光谱的完整图景

从强到弱：严格一致性 > 线性一致性 > 顺序一致性 > 因果一致性 > 最终一致性。每个级别的核心保证是什么，它们之间的关系是什么。

#3. 选型的权衡思维

不是「越强越好」，而是「根据业务需求选择最合适的」。金融系统需要线性一致性，社交媒体可以接受最终一致性，协作工具需要因果一致性。

#4. 典型系统的对应关系

• etcd / ZooKeeper：线性一致性
• DynamoDB / Cassandra：最终一致性（可配置）
• SequalDB：顺序一致性

#5. 实现代价的理解

强一致性需要共识协议、跨节点协调，这会带来延迟。理解为什么因果一致性比线性一致性快，最终一致性比因果一致性快。

#思考题

问题 1：如果一个系统声称「同时满足 CAP 三角的三个方面」，这是可能的吗？

问题 2：DynamoDB 默认是最终一致性，但它是如何在「不需要用户处理冲突」的场景下工作的？

问题 3：因果一致性比线性一致性「弱」，但为什么说它仍然是一种「强一致性」？

#术语表

#延伸阅读

如果你对一致性模型还想深入，可以继续探索：

• 悲观 vs 乐观并发控制：一致性模型是「悲观」的（假设冲突一定会发生），而乐观锁是「乐观」的（假设冲突很少发生）
• 柔性事务（BASE）：与 ACID 事务相对，BASE 强调基本可用、软状态、最终一致
• CRDT（无冲突复制数据类型）：一种可以在最终一致性系统下实现强语义的特殊数据结构

一致性是分布式系统中最核心的话题之一。希望这个系列文章能帮助你建立起完整的知识体系，在未来的系统设计中做出明智的权衡。