Redis 集群保证数据一致性的核心机制详解‌

1. 主从复制与数据同步‌

1.1 主从角色定义‌

主节点（Master）‌：负责处理所有写操作，并将数据变更异步或半同步复制到从节点‌。
从节点（Slave）‌：仅处理读请求，接收主节点的数据同步‌。

1.2 同步流程‌

全量同步（首次连接）‌：
从节点发送 SYNC 命令给主节点‌。
主节点生成 ‌RDB 快照‌并缓存期间的写命令，发送给从节点‌。
从节点加载快照并执行缓存命令，完成数据初始化‌。
增量同步（后续更新）‌：
主节点维护 ‌复制缓冲区（Replication Buffer）‌，记录增量写命令‌。
从节点周期性发送 PSYNC 命令，获取缓冲区中的增量数据‌。

1.3 数据一致性风险‌

异步复制延迟‌：默认异步复制可能导致从节点数据短暂滞后‌。
脑裂问题‌：主节点与集群断开后，若原主节点仍在处理写操作，可能导致数据冲突（需依赖哨兵或集群自愈机制解决）‌。
2. 哈希槽分片与数据分布‌

2.1 哈希槽分配‌

槽位总数‌：固定 16384 个槽位，每个主节点负责部分槽位（如 3 主节点时，每个节点约 5461 个槽）‌。
数据路由‌：客户端通过 CRC16(key) % 16384 计算键的槽位，路由到对应主节点‌。

2.2 动态分片（ReSharding）‌

槽位迁移‌：
源节点和目标节点协商迁移槽位，原子化转移键值数据‌。
迁移过程中，客户端访问旧节点时可能被重定向到新节点‌。
一致性保证‌：
迁移期间，客户端请求可能短暂访问旧数据（需依赖重试机制）‌。
3. Gossip协议与集群状态维护‌

3.1 节点通信机制‌

PING/PONG 消息‌：节点周期性交换存活状态、槽位分配、配置纪元等信息‌。
故障检测‌：若节点在超时时间内未响应，集群标记其为下线并触发故障转移‌。

3.2 配置纪元（Epoch）‌

唯一递增编号‌：每次集群拓扑变更（如主从切换）时递增，用于解决脑裂冲突（仅接受更高纪元号的节点决策）‌。
4. 写操作传播与确认机制‌

4.1 默认异步复制‌

主节点处理写操作后直接返回成功，异步复制到从节点‌。
优点‌：高性能；‌缺点‌：故障时可能丢失未同步数据‌。

4.2 强一致性配置‌

WAIT 命令‌：客户端可强制等待 N 个从节点同步完成（如 WAIT 1 5000 表示等待 1 个从节点同步，超时 5 秒）‌。
性能代价‌：同步等待增加延迟，降低吞吐量‌。
5. 持久化与容灾恢复‌

5.1 RDB 快照‌

周期性生成‌：定时保存内存快照，恢复速度快，但可能丢失最后一次快照后的数据‌。

5.2 AOF 日志‌

实时记录‌：追加写入所有写命令，支持更细粒度恢复（如 appendfsync everysec 平衡性能与安全性）‌。

5.3 混合持久化（Redis 4.0+）‌

RDB + AOF‌：重启时先加载 RDB 快照，再重放 AOF 增量日志，兼顾恢复速度与数据完整性‌。
6. 事务与原子性操作‌

6.1 事务（MULTI/EXEC）‌

单节点原子性‌：事务内命令在单个节点顺序执行，但集群模式下需确保所有键位于同一槽位‌。

6.2 Lua 脚本‌

原子执行‌：脚本内的命令在单个节点原子执行（需保证键在同一槽位）‌。
关键设计权衡与最佳实践‌

一致性级别选择‌：

强一致性‌：适用金融交易等场景，需牺牲性能‌。
最终一致性‌：适用缓存、计数器等高并发场景‌。

故障转移优化‌：

启用哨兵模式‌：自动监控主节点状态并触发故障转移‌。
避免跨槽操作‌：设计键时使用哈希标签（如 {user123}.profile）确保相关键位于同一槽位‌。

监控与调优‌：

跟踪同步延迟‌：使用 INFO replication 监控主从延迟‌。
调整持久化策略‌：根据数据重要性选择 RDB/AOF 或混合模式‌。