一、高可用总览类
Q1：Redis 高可用有哪些方案？
Q2：Redis 高可用要解决什么问题？
数据冗余：主挂了从库还有数据。
故障转移：主挂了自动提升从库。
读写分离：读走从库，分摊压力。
水平扩展：Cluster 分片。
Q3：主从、哨兵、Cluster 的关系？
主从是基础，哨兵在主从上加自动切换。
Cluster 是分片方案，每个分片内部也是主从。
哨兵管不了分片，Cluster 自带故障转移。
二、主从复制类
Q4：Redis 主从复制的原理？
从库连接主库，发送
PSYNC。首次同步：主库
BGSAVE生成 RDB，发给从库。从库加载 RDB，之后主库把增量命令发给从库。
持续同步：主库每写一条命令就传播给从库。
Q5：全量同步和增量同步的区别？
Q6：什么是 repl_backlog？
主库的环形缓冲区，存最近传播的写命令。
从库断连重连时，如果 offset 还在 backlog 里，就增量同步。
否则全量同步。
大小由
repl-backlog-size控制。
Q7：什么是复制偏移量（offset）？
主库和从库各自维护一个 offset。
主库每传播 N 字节命令，offset 增加 N。
从库每收到 N 字节，offset 增加 N。
通过对比 offset 判断是否一致。
Q8：什么是 runid？
每个 Redis 实例启动时生成的唯一 ID。
从库记录主库的 runid。
主库重启后 runid 变化，从库会触发全量同步。
Q9：全量同步的过程？
从库发
PSYNC ? -1。主库
BGSAVE生成 RDB。主库把 RDB 发给从库。
期间新命令写入 repl_backlog。
从库加载 RDB 后，主库发 backlog 中的增量。
进入命令传播阶段。
Q10：增量同步的过程？
从库发
PSYNC runid offset。主库检查 runid 和 offset。
offset 在 backlog 范围内，返回
+CONTINUE。主库发 offset 之后的命令。
从库执行，追上主库。
Q11：主从复制是同步还是异步？
异步。主库写完后立即返回，不等从库。
所以主库挂了可能丢数据。
要更强一致用
WAIT命令或 Cluster。
Q12：主从延迟怎么排查？
INFO replication看master_repl_offset和slave_repl_offset。差值大说明延迟。
看从库
master_link_status是否 up。
Q13：主从复制的缺点？
异步，可能丢数据。
主库挂了不会自动切换（需哨兵）。
从库只读，写压力仍在主库。
全量同步开销大。
三、哨兵 Sentinel 类
Q14：哨兵是什么？
独立进程，监控 Redis 主从。
功能：监控、通知、自动故障转移、配置中心。
通常部署 3 个或以上哨兵，奇数个。
Q15：哨兵的工作原理？
每个哨兵定期
PING主从。主观下线：单个哨兵认为节点挂了。
客观下线：多数哨兵认为主库挂了。
选举 Leader 哨兵。
Leader 选一个从库提升为主。
其他从库指向新主。
通知客户端新主地址。
Q16：主观下线和客观下线的区别？
主观下线（SDOWN）：单个哨兵认为节点不可用。
客观下线（ODOWN）：超过
quorum个哨兵认为主库不可用。只有主库才需要客观下线，从库主观下线即可。
Q17：哨兵怎么选新主？
优先级：
排除不健康的从库。
replica-priority小的优先。复制 offset 大的优先（数据新）。
runid 小的优先。
Q18：哨兵怎么选举 Leader？
基于 Raft 算法。
需要多数派（majority）同意。
所以哨兵数要是奇数，至少 3 个。
Q19：quorum 和 majority 的区别？
quorum：判断客观下线需要的票数。
majority：选举 Leader 需要的票数，是哨兵总数的一半 + 1。
例：3 个哨兵，quorum=2，majority=2。
Q20：哨兵怎么通知客户端？
哨兵是配置中心，客户端订阅哨兵获取主库地址。
故障转移后，哨兵发布新主地址。
客户端（如 Jedis、Lettuce）自动重连新主。
Q21：哨兵能解决分片吗？
不能。哨兵只管主从切换，不管分片。
数据量超过单机内存要用 Cluster。
Q22：哨兵模式有什么问题？
故障转移期间短暂不可用。
脑裂风险：网络分区可能双主。
客户端要支持哨兵。
配置复杂。
四、Cluster 类
Q23：Redis Cluster 是什么？
官方分片方案，Redis 3.0+。
数据按 16384 个槽分片到多个节点。
每个节点负责一部分槽。
每个分片内部是主从，支持故障转移。
Q24：Cluster 的槽是什么？
共 16384 个槽（0~16383）。
key 通过
CRC16(key) % 16384计算槽。每个主节点负责一部分槽。
槽信息由集群总线传播。
Q25：为什么是 16384 个槽？
16384 = 2^14，心跳包用 bitmap 表示槽，2KB 合适。
槽太多心跳包大，太少分片不均。
作者权衡后的选择。
Q26：什么是 MOVED 和 ASK？
MOVED：槽已永久迁移到其他节点，客户端应更新路由。
ASK：槽正在迁移，临时重定向到目标节点。
客户端收到后要重新请求。
Q27：Cluster 的故障转移？
节点间通过 gossip 通信。
主节点挂了，从节点检测到。
从节点发起选举，需要多数主节点同意。
选上的从节点提升为主，接管槽。
广播新配置。
Q28：Cluster 的集群总线是什么？
节点间通信的二进制协议，端口 = 客户端端口 + 10000。
用于 gossip、心跳、配置传播、故障检测。
Q29：Cluster 支持多键操作吗？
支持，但所有 key 必须在同一槽。
用 hash tag
{}强制同槽，如{user}:1、{user}:2。跨槽操作报
CROSSSLOT错误。
Q30：Cluster 的最小规模？
至少 3 主 3 从，共 6 个节点。
保证多数派和容错。
生产建议更多。
Q31：Cluster 有什么限制？
不支持多数据库，只有 db0。
跨槽多键操作受限。
Lua 脚本 key 要同槽。
客户端要支持 Cluster。
运维复杂。
五、故障转移与一致性类
Q32：主库挂了，数据会丢吗？
异步复制下，可能丢未同步的数据。
用
WAIT命令可等从库确认。Cluster 下多数派确认减少丢失。
Q33：什么是脑裂？
网络分区导致出现两个主库。
客户端可能写到旧主，数据丢失。
哨兵用多数派减少风险。
Cluster 用多数派选举。
Q34：怎么减少故障转移丢数据？
min-replicas-to-write：至少 N 个从库才允许写。min-replicas-max-lag：从库延迟不超过 M 秒。WAIT命令同步等待。Cluster 多数派。
Q35：故障转移期间服务可用吗？
短暂不可用（秒级到十几秒）。
客户端要能重试。
哨兵/Cluster 自动完成切换。
Q36：主从切换后客户端怎么感知？
哨兵：客户端订阅哨兵，自动获取新主。
Cluster：客户端收到 MOVED，更新路由。
需要客户端库支持。
六、实战与选型类
Q37：主从、哨兵、Cluster 怎么选？
Q38：哨兵和 Cluster 能一起用吗？
一般不一起用。
Cluster 自带故障转移，不需要哨兵。
混用增加复杂度。
Q39：Cluster 怎么扩容？
加新节点，
redis-cli --cluster add-node。迁移槽：
redis-cli --cluster reshard。迁移期间 ASK 重定向。
建议低峰操作。
Q40：怎么监控 Redis 高可用？
INFO replication：主从状态、offset。INFO sentinel：哨兵状态。CLUSTER INFO、CLUSTER NODES：集群状态。监控主从延迟、故障转移次数。
七、高频陷阱题
Q41：主从复制是强一致吗？
不是。默认异步，可能丢数据。
WAIT可增强，但不是强一致。Cluster 多数派也不是强一致。
Q42：哨兵能监控 Cluster 吗？
不需要。Cluster 自带故障转移。
哨兵管不了分片。
Q43：Cluster 的从节点能读吗？
默认从节点只读。
可
READONLY命令让从节点提供读。但可能读到旧数据。
Q44：Cluster 挂一个主会怎样？
其从节点提升为主，接管槽。
短暂不可用。
如果主从都挂，槽不可用，集群可能下线。
Q45：哨兵挂了会怎样？
多个哨兵时，剩余哨兵继续工作。
少于多数派无法故障转移。
所以哨兵要至少 3 个。
Q46：全量同步会阻塞主库吗？
BGSAVEfork 会短暂阻塞。传输 RDB 占网络和磁盘。
大实例全量同步开销大。
Q47：怎么避免频繁全量同步？
合理设置
repl-backlog-size。保证网络稳定。
避免主库频繁重启。
从库
repl-timeout合理。
评论