适用读者：要定"Redis 怎么部署才不丢数据"的人。
前置：S12-B04（持久化）。
覆盖旧文：883(101) 884(89) 885(82) 1573(131) 1568(517) = 920 点。
覆盖扩展：E-S12-009（异步复制丢数据）、E-S12-010（脑裂与 min-replicas-to-write）。
上一篇：S12-J05 · 高级用法：延迟队列 / 订阅 / 限流 / SCAN
下一篇：S12-A02 · 热 Key 与大 Key 治理。

---

1. 一句话结论

主从解决"读扩展 + 备份"，哨兵解决"自动切换"，Cluster 解决"分片容量"。但前两者都是异步复制——切换就会丢最后那一小段写入。

方案	解决	容量	丢数据风险
主从	读扩展、备份	单机内存	切换时丢
哨兵	自动故障转移	单机内存	切换时丢
Cluster	分片（16384 slot）	横向扩展	同左

---

2. 异步复制为什么会丢（E-S12-009）

主库写内存 → 返回客户端成功 → 异步发往从库 →（此时主库宕机）
                                ↓
                        从库没有这条数据 → 被提升为主 → 数据丢失

注意：这是所有"异步复制"的通病（MySQL 主从同样，S11-J05）。

缓解：

手段	说明
WAIT numreplicas timeout	等 N 个从库确认（同步语义，但增加延迟）
min-replicas-to-write	从库不足时拒绝写（牺牲可用性换一致性）

---

3. 脑裂（E-S12-010）

场景：主库与哨兵/集群网络分区 → 哨兵认为主库挂了 → 提升从库；但旧主库还活着，仍在接收写 → 恢复后这部分写丢失。

防护	机制
min-replicas-to-write + min-replicas-max-lag	从库不足/延迟太大 → 主库拒绝写
cluster-require-full-coverage（Cluster）	部分槽不可用则整体拒绝（权衡）
业务侧幂等 + 对账	最终兜底

判据："丢几秒数据能接受吗？" 不能 → 必须配 min-replicas-to-write，并接受"从库不足时写失败"。

---

4. Cluster 的三个硬约束

约束	说明
多 key 操作需同 slot	用 {hash tag} 强制同槽
不支持多 DB	只有 db0
客户端需支持重定向	MOVED/ASK

"为什么 16384 个槽"：作者给出的经验值——心跳包大小与节点数的折中（16384 bit = 2KB 位图）。

---

5. 与 Zookeeper 的对比（A-1573）

维度	Redis Cluster	ZooKeeper
定位	缓存集群	协调服务（强一致）
一致性	最终一致	顺序一致（ZAB）
用途	数据分片	选主、配置、分布式锁
运维	较简单	重（多数派）

判据："要选主/协调吗？" 要 → ZK/etcd；只是缓存分片 → Cluster。

---

6. 五个误区

误区	真相
"主从切换不丢数据"	异步复制必丢
"脑裂只会发生在集群"	主从+哨兵也会
"Cluster 支持多 key 任意操作"	需同 slot
"Redis 能当协调服务"	不是强一致系统
"加从库能提升写性能"	从库只分担读

---

7. 自检（架构师版）

1. 三种部署各解决什么问题？
2. 异步复制丢数据的窗口在哪？
3. min-replicas-to-write 的代价是什么？
4. Cluster 的三个硬约束？
5. 什么时候该用 ZK/etcd 而不是 Redis？

---

8. 下一篇

S12-A02 · 热 Key 与大 Key 治理

集群讲完，下一篇讲"一个 key 如何打爆集群"：热 key 探测、大 key 拆分与删除。

---

本篇属于系列《S12 · Redis 与缓存》。旧文来源：A-883/884/885/1573/1568；扩展点 E-S12-009/010。