CP vs AP 系统选型指南#

#一、CP 与 AP 的本质区别

#CP 系统：在分区时放弃可用性

CP 系统的核心特征是：宁可停止服务，也不返回不一致的数据。

当网络分区发生时，CP 系统会：

1. 检测到分区
2. 停止部分节点的响应（因为无法保证一致性）
3. 在分区恢复后，进行数据同步
4. 恢复服务

代表系统包括：ZooKeeper、etcd、HBase、MongoDB（副本集模式）、Redis Sentinel

#AP 系统：在分区时放弃一致性

AP 系统的核心特征是：宁可返回旧数据，也要保证服务可用。

当网络分区发生时，AP 系统会：

1. 检测到分区
2. 让各分区独立继续服务
3. 在分区恢复后，通过后台同步或冲突解决机制逐步恢复一致
4. 可能产生「脑裂」——多个分区各自为政

代表系统包括：Eureka、Cassandra、DynamoDB、Redis Cluster

#二、典型系统分析

#ZooKeeper：CP 的教科书

ZooKeeper 是 CP 系统的典型代表。它的 ZAB 协议（ZooKeeper Atomic Broadcast）保证了：

• 强一致性：所有节点对状态的看法完全一致
• 原子性：写入要么在所有节点成功，要么失败
• 分区容忍：能够容忍网络故障

flowchart LR
    subgraph 正常状态
        L["Leader<br/>ZNode-1"] --> F1["Follower<br/>ZNode-2"]
        L --> F2["Follower<br/>ZNode-3"]
    end
    
    subgraph 分区状态
        L2["Leader<br/>ZNode-1"] 
        F1_2["Follower<br/>ZNode-2"]
        F2_2["Follower<br/>ZNode-3"]
    end
    
    正常状态 -->|"网络分区"| 分区状态

当网络分区导致 Follower 与 Leader 失联时：

• Leader 所在的分区继续工作
• 失联的 Follower 被视为「不存在」
• 如果无法达成多数派写入，系统会停止服务

这就是为什么 ZooKeeper 适合做分布式协调服务（如分布式锁、配置管理），但不适合做需要高可用的服务发现——想象一下，当你的 Kubernetes Master 节点网络抖动时，整个集群的服务发现突然不可用……

#Eureka：AP 的践行者

Netflix 设计 Eureka 的核心理念是：服务注册中心必须是永远可用的。

Eureka 的工作方式完全不同：

• 每个 Eureka Server 节点都是对等的，都可以接受服务注册
• 服务启动时向所有 Eureka Server 注册
• 节点之间通过心跳同步数据（但不保证强一致）
• 分区期间，每个分区独立继续工作

sequenceDiagram
    participant S as 服务实例
    participant E1 as Eureka-1
    participant E2 as Eureka-2
    
    S->>E1: 注册 + 发送心跳
    S->>E2: 注册 + 发送心跳
    Note over S,E2: 正常同步状态
    
    E1-xE2: 网络分区
    Note over E1: 继续接受心跳<br/>服务正常
    Note over E2: 继续接受心跳<br/>服务正常
    
    E2->>E1: 分区恢复，同步数据

Eureka 的代价是：

• 可能出现「脏读」：消费者可能读到已下线服务的注册信息
• 数据不是强一致的：不同节点的注册表可能暂时不同
• 依赖客户端缓存：Eureka 客户端会缓存注册表，以应对 Server 不可用

#Redis：两种模式的集合

Redis 是一个有趣的案例：它同时支持 CP 和 AP 两种模式，取决于你使用哪种部署架构。

Redis Sentinel（CP）：当主节点故障时，Sentinel 会通过 Raft 协议选举新主。在选举期间，整个集群不可写。一旦新主当选，数据会从旧主同步过来，然后恢复服务。

Redis Cluster（AP）：每个分片都有主从节点，但分片之间是独立的。当某个分片的主节点故障时，该分片的从节点会升级为主节点。但其他分片继续正常服务。这就是 Redis Cluster 能够在部分分区时继续服务的原理。

#三、权衡矩阵：如何选择

选 CP 还是 AP，不是非此即彼的选择题。它需要基于业务场景进行权衡。

#核心权衡维度

#选型决策树

flowchart TD
    A["业务场景分析"] --> B{"数据一致性要求？"}
    B -->|"不允许任何不一致<br/>金融、库存、账户"| C["CP 系统"]
    B -->|"可以容忍短暂不一致<br/>评论、Feed、缓存"| D["可用性要求？"]
    
    D -->|"必须 7×24 可用<br/>用户直接感知"| E["AP 系统"]
    D -->|"允许短暂不可用<br/>后台任务"| F["根据延迟要求选择"]
    
    C --> G["ZooKeeper<br/>etcd<br/>HBase"]
    E --> H["Eureka<br/>Cassandra<br/>Redis Cluster"]
    F --> I["低延迟优先：AP<br/>一致性优先：CP"]
    
    style C fill:#f96
    style E fill:#9f9
    style F fill:#ff9

#场景化选型建议

#四、混合方案：CP + AP 的实践

Netflix 的实践告诉我们：大型系统往往需要同时使用 CP 和 AP 系统，它们服务不同的业务需求。

#Netflix 的混合架构

Netflix 的服务治理架构同时包含：

• Eureka（AP）：服务注册与发现，保证服务在任何时候都可被发现
• Zuul/APIGateway：路由层，根据 Eureka 的信息进行负载均衡
• Hystrix/Resilience4j：熔断器，在服务不可用时快速失败
• Archaius：配置中心，使用 ZooKeeper（CP）保证配置一致性

这种设计的思路是：

1. 用 AP 系统处理「让服务活着」的问题
2. 用 CP 系统处理「让数据正确」的问题
3. 用 熔断器在两者之间建立隔离层

#混合选型的决策框架

                    ┌─────────────────┐
                    │  业务需求分析   │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
      ┌───────────┐  ┌───────────┐  ┌───────────┐
      │ 数据一致性 │  │ 可用性要求 │  │ 延迟容忍度 │
      │ 要求极高   │  │ 极高       │  │ 低         │
      └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
            │              │              │
            ▼              ▼              ▼
      ┌───────────┐  ┌───────────┐  ┌───────────┐
      │   CP      │  │   AP      │  │ 需要混合   │
      │ ZooKeeper │  │  Eureka   │  │ CP + AP   │
      └───────────┘  └───────────┘  └───────────┘

#五、真实案例：选型踩坑记

#案例一：电商公司 ZooKeeper 选型失败

#案例二：金融公司 Eureka 选型后的噩梦

#六、反模式：同时要求强一致和强可用

flowchart TD
    A["「我想要强一致+高可用」"] --> B{"真的吗？"}
    B -->|"是的，网络永远不会故障"| C["单机系统"]
    B -->|"不，分区必然发生"| D["必须在 C 和 A 之间选择"]
    
    D --> E["CP：一致性优先<br/>牺牲可用性"]
    D --> F["AP：可用性优先<br/>牺牲一致性"]
    
    style C fill:#f96
    style E fill:#9f9
    style F fill:#9f9