针对 Redis 源码分析 CAP 定理（一致性、可用性、分区容错性），需要结合 Redis 的架构设计（如单机模式、主从复制、哨兵机制、集群模式）及其源码实现逻辑。以下从 CAP 三要素出发，结合源码关键模块分析 Redis 的设计取舍与实现细节。

一、CAP 定理在 Redis 中的定位

Redis 是典型的 AP 系统（牺牲强一致性，保证分区容错性和可用性，最终一致性）。其设计目标是高可用、高性能的内存数据存储，因此在分布式场景下（如主从集群、Redis Cluster）优先保证：

• 分区容错性（P）：支持网络分区时的系统可用性。
• 可用性（A）：尽可能提供服务（读 / 写），避免因分区导致系统不可用。
• 一致性（C）：仅保证最终一致性（异步复制机制可能导致数据丢失或短暂不一致）。

二、Redis 单机模式：不涉及分布式 CAP

单机 Redis 是单一节点，无分区问题，因此：

• 分区容错性（P）：不适用（无分布式节点）。
• 一致性（C）：单线程串行处理命令，天然保证强一致性（基于内存操作，无并发写入冲突）。
• 可用性（A）：依赖单点可靠性（如故障则服务中断）。

源码角度：

• 单机模式核心在 server.c 中，通过 aeMain() 事件循环处理请求，单线程保证命令执行的原子性和顺序性，无需考虑分布式一致性协议。

三、主从复制（Master-Slave）的 CAP 分析

1. 分区容错性（P）

主从节点通过网络连接，当发生网络分区（如主从断连）时：

• 源码机制：从节点在 replication.c 中通过 master-repl-offset 记录复制偏移量，主节点通过 master.repl_backlog 环形缓冲区保存未同步的写命令。网络恢复后，从节点通过 PSYNC 命令尝试部分重同步（Partial Resync），减少全量复制开销。
• 分区处理：主节点继续处理写请求（可用性优先），从节点暂时滞后（允许数据不一致）。分区期间主节点的写命令可能未同步到从节点，导致一致性损失。

2. 可用性（A）

• 主节点故障前，从节点可提供只读服务（通过 slave-read-only 配置），保证读可用性。
• 源码缺陷：主节点故障后，需人工或哨兵（Sentinel）介入故障转移，期间服务可能中断（单机主节点不可用）。从节点晋升为主节点的逻辑在 sentinel.c 的 sentinelFailover 函数中实现，依赖选举机制（类似 Raft 的简化版）。

3. 一致性（C）

• 异步复制：主节点在 replication.c 的 replicationFeedSlaves 中异步发送写命令到从节点，不等待从节点确认即返回客户端。若主节点在命令发送前故障，从节点未收到该命令，导致数据丢失（最终一致性）。
• 强一致性的妥协：Redis 4.0 引入 min-replicas-to-write 和 min-replicas-max-lag 配置，要求至少 N 个从节点滞后不超过 M 秒时才接受写请求，提升一致性，但牺牲部分可用性（若从节点不足则拒绝写）。

四、哨兵机制（Sentinel）的 CAP 增强

哨兵是 Redis 的高可用解决方案，核心目标是自动故障转移，提升可用性和分区容错性。

1. 分区容错性（P）

• 哨兵集群通过 gossip 协议（sentinel.c 的 sentinelTimer 函数）检测节点状态，允许部分哨兵节点与主节点分区。
• 当主节点不可达时，哨兵通过 多数派投票（sentinel.c 的 sentinelGetMasterAddrBySocket 中的 Quorum 机制）确认主节点下线（ODOWN 状态），避免脑裂。

2. 可用性（A）

• 故障转移流程：哨兵选举 Leader（sentinel.c 的 sentinelSelectLeader）。Leader 触发从节点晋升为主节点（sentinel.c 的 sentinelFailover）。重新配置其他从节点指向新主节点。
• 源码关键点：通过 sentinelAuthUser 等函数处理节点认证，确保故障转移的安全性。采用超时机制（down-after-milliseconds）判断节点故障，避免误判。

3. 一致性（C）

• 故障转移期间可能存在短暂的不一致：原主节点恢复后成为从节点，可能丢失故障前未同步的写命令（由 repl_offset 保证从新主节点复制）。哨兵通过 config-epoch（配置纪元，sentinel.c 中的 current_epoch）避免旧配置的节点成为主节点，保证集群视图的一致性。

五、Redis Cluster（集群模式）的 CAP 实现

Redis Cluster 是分布式分片集群，每个节点负责部分槽（Slot，共 16384 个），通过 Gossip 协议同步节点状态（cluster.c 的 clusterCron 函数）。

1. 分区容错性（P）

• 当网络分区导致集群分裂为多个子集群时：若子集群包含至少半数主节点（针对仲裁机制），则继续提供服务（可用性优先）。否则，整个集群进入不可用状态（如主节点数不足半数，无法完成故障转移投票）。
• 源码逻辑：节点通过 clusterState 结构体维护集群状态，clusterHandleSlaveOf 处理节点角色变更。clusterReplicate 函数实现槽迁移，支持在线扩缩容时的分区调整。

2. 可用性（A）

• 读请求可由主节点或从节点处理（通过 cluster-require-full-coverage 配置控制）。
• 写请求只能由主节点处理，从节点故障不影响写可用性；主节点故障时，从节点晋升需满足多数派投票（cluster-node-timeout 控制检测超时）。

3. 一致性（C）

• 异步复制 + 最终一致性：主节点处理写命令后，异步复制到从节点（同主从模式），可能因分区导致从节点数据滞后。集群通过 CLUSTER ADDSLOTS 等命令保证槽与节点映射的强一致性（元数据存储在每个节点的 clusterState.slots_to_nodes 数组中）。
• 写冲突处理：同一键的写操作由单一主节点处理，避免分布式事务（Redis 不支持跨节点强一致性写）。

六、Redis 源码中 CAP 相关的关键参数与函数

七、总结：Redis 对 CAP 的权衡

1. 分区容错性（P）：通过主从复制、哨兵选举、集群 Gossip 协议，确保在网络分区时系统仍能部分运行。
2. 可用性（A）：优先保证读 / 写服务可用（如从节点可读、快速故障转移），牺牲强一致性。
3. 一致性（C）：单机模式：强一致性。分布式模式：最终一致性（异步复制、允许短暂数据丢失），通过配置（如 min-replicas）可调优一致性级别。

源码本质：Redis 通过 异步复制 + 轻量级选举协议 + 最终一致性元数据同步，在 AP 模型下实现高可用和分区容错，适合缓存、实时统计等对一致性要求不高的场景。若需强一致性，需结合外部系统（如分布式事务中间件）或使用 Redis 的同步复制功能（牺牲性能）。