单节点 Redis 再快，也会遇到三个问题：
- 单节点并发能力有上限。
- 单节点宕机会导致服务不可用。
- 单节点内存有限，无法承载海量数据。
Redis 的集群方案就是围绕这三个问题展开的：主从复制解决读扩展，哨兵解决自动故障恢复，分片集群解决海量数据和高并发写。
一、主从复制：读写分离
主从复制通常是一主多从。主节点负责写，从节点负责读，从而提高整体并发能力。
Redis Client
Master 写
Slave 读
Slave 读
主从复制适合读多写少的场景。但它只解决读扩展，不解决 Master 宕机后的自动切换问题。
二、主从同步：全量同步和增量同步
第一次同步通常是全量同步：
Master Slave Master Slave 请求同步，携带 replication id 和 offset 判断是否第一次同步 执行 bgsave 生成 RDB 发送 RDB 文件 发送期间缓冲的写命令 加载 RDB 并执行命令
如果从节点短暂断开后重连，Master 会根据 offset 从 repl_backlog 中找到断开期间的命令，做增量同步。
三、哨兵：自动故障恢复
Sentinel 哨兵机制用于主从集群的自动故障恢复。它主要做三件事：
| 功能 | 说明 |
|---|---|
| 监控 | 定期 ping 主从节点，检查服务状态 |
| 自动故障恢复 | Master 宕机后，从 Slave 中选举新 Master |
| 通知 | 通知客户端新的 Master 地址 |
哨兵通过心跳判断节点状态：
| 状态 | 含义 |
|---|---|
| 主观下线 | 某个 Sentinel 认为节点不可用 |
| 客观下线 | 超过 quorum 数量的 Sentinel 都认为节点不可用 |
quorum 最好超过 Sentinel 实例数量的一半。
四、脑裂：为什么会出现两个 Master？
脑裂通常发生在网络分区时。老 Master 和 Sentinel 失去联系，Sentinel 认为 Master 下线，于是把某个 Slave 提升为新 Master。但客户端可能仍然能连接老 Master，并继续写入数据。
网络分区
Sentinel 感知不到老 Master
提升 Slave 为新 Master
客户端仍向老 Master 写入
出现两个 Master
数据不一致风险
课件里给了两个配置来降低脑裂风险：
conf
min-replicas-to-write 1
min-replicas-max-lag 5含义是：至少要有 1 个从节点，并且复制延迟不能超过 5 秒，否则 Master 拒绝写入。这样老 Master 如果和从节点失联，就不会继续接收写请求。
五、分片集群：解决海量数据和高并发写
主从和哨兵解决了高可用和高并发读，但没有解决两个问题：
- 海量数据存储。
- 高并发写。
分片集群中会有多个 Master，每个 Master 保存不同的数据，每个 Master 又可以有多个 Slave。
客户端
Master 1
Master 2
Master 3
Slave
Slave
Slave
客户端可以访问集群任意节点，最终请求会被转发到正确节点。
六、哈希槽：key 到底存在哪个节点？
Redis Cluster 引入了哈希槽。整个集群有 16384 个槽，每个 key 通过 CRC16 校验后对 16384 取模，得到槽位。
text
slot = CRC16(key) % 16384每个 Master 负责一部分槽。例如：
| 节点 | 负责槽位 |
|---|---|
| Master 1 | 0 - 5460 |
| Master 2 | 5461 - 10922 |
| Master 3 | 10923 - 16383 |
如果 key 中有大括号，Redis 会使用大括号里的内容作为有效部分计算槽位：
text
user:{1001}:name
order:{1001}:list这样可以让相关 key 落到同一个槽，便于执行某些多 key 操作。
七、怎么选集群方案？
| 场景 | 推荐方案 |
|---|---|
| 小型项目，Redis 压力不大 | 单机或一主一从 |
| 需要自动故障恢复 | 主从 + 哨兵 |
| 数据量大，写压力高 | Redis Cluster 分片集群 |
| 单节点内存超过 10G | 优先考虑拆分服务或分片 |
面试可以这样说：
Redis 集群方案主要有主从复制、哨兵和分片集群。主从复制通过读写分离提升读并发；哨兵在主从基础上增加监控、自动故障转移和通知能力；分片集群通过多个 Master 分摊数据和写压力，并通过 16384 个哈希槽决定 key 的存储位置。脑裂可以通过限制最少从节点数量和最大复制延迟来降低风险。