Redis高可用那些事儿，面试中常碰到的重点和题目解析

说到Redis的高可用，这绝对是面试里的高频话题，尤其是当你面试的岗位需要接触系统稳定性或大量用户数据时，面试官想知道的不是你仅仅听说过“高可用”这个词，而是你真的理解怎么保证Redis在出问题时还能继续提供服务,下面我就把这里面的重点和常见题目给你捋一捋。

核心思想：别把鸡蛋放在一个篮子里

高可用的核心很简单，就是防止“单点故障”，如果整个系统就靠一个Redis实例撑着，那这个实例一旦宕机（比如机器坏了、断电了），整个服务就瘫痪了，高可用方案的本质就是“备份”和“自动切换”。

主从复制——高可用的基石

这是最基础也是必须懂的概念，你可以把它想象成一个老板（主节点）带着几个秘书（从节点）干活。

• 怎么工作？ 老板写的所有数据（写操作），都会自动同步给秘书们，读操作可以让秘书们分担，但只有老板能写，这样既减轻了老板的压力,也保证了数据有多个备份。
• 面试常问：
  • 主从复制的流程是怎样的？ （参考答案：从节点启动后，会向主节点发送同步命令；主节点会生成一个当前数据的快照（RDB文件）发给从节点；主节点会把期间新的写命令缓存在一个“复制缓冲区”里；从节点加载完RDB后，主节点再把缓冲区里的新命令发过去，这样就同步上了。）
  • 主从复制是同步的还是异步的？ （参考答案：默认是异步的，意思是主节点写完数据，立刻返回成功给客户端，然后再异步地把数据同步给从节点，这样性能好，但有个风险：如果主节点在数据同步给从节点之前宕机了，那部分数据就丢失了。）
  • 主从复制有什么缺点？ （参考答案：1. 异步复制可能导致数据丢失，2. 主节点挂了后，无法自动选举出新的主节点，需要人工干预，服务会中断一段时间，所以单纯的主从复制并不能实现真正的高可用。）

哨兵模式——实现自动故障切换

为了解决主从复制“无法自动选主”的问题，哨兵（Sentinel）模式登场了，你可以把哨兵想象成一群监工，它们不干活（不存储数据）,只负责盯着老板和秘书们的健康状况。

• 怎么工作？ 哨兵是一个独立的进程，通常会部署多个（比如3个或5个，防止自己成为单点），它们会持续监控所有主从节点，当多数哨兵都认为主节点“失联”时，它们就会自动开会投票，从秘书（从节点）中选举出一个新的老板（主节点），然后通知其他的秘书们去新的老板那里报到，它会通知客户端（比如你的应用程序）主节点已经换了人。
• 面试常问：
  • 哨兵是如何判断主节点宕机的？ （参考答案：主要通过“心跳检测”，每个哨兵会定期向主节点发送PING命令，如果在一定时间内没收到回复，它就认为主节点“主观下线”，但它一个人说了不算，它会告诉其他哨兵，当足够数量的哨兵（比如超过一半）都认为主节点下线了，就达成“客观下线”的共识，然后开始故障转移。）
  • 客户端是如何知道新的主节点地址的？ （参考答案：客户端会先连接哨兵集群，询问当前的主节点地址是多少，当故障切换发生后，客户端再次向哨兵询问，就能得到新主节点的地址，常见的Redis客户端库（如Jedis、Lettuce）都支持这种自动发现机制。）
  • 哨兵模式有什么优缺点？ （参考答案：优点：实现了自动故障转移，真正做到了高可用，缺点：1. 故障转移期间数据可能丢失（因为主从复制是异步的），2. 集群的存储容量受限于单个主节点的内存大小，无法海量扩容。）

Redis Cluster——应对海量数据与高并发

当数据量非常大，一个机器根本存不下，或者写操作多到一个主节点扛不住时，就要用到Redis Cluster（集群模式）了，它的核心思想是“分片”（Sharding）。

• 怎么工作？ 它把整个数据分成16384个槽位（slot），你可以部署很多个主节点，每个主节点负责一部分槽位，数据根据key计算一个哈希值，然后对16384取模，决定它存放在哪个槽位，进而存放在哪个主节点上，每个主节点也有自己的从节点做备份，Redis Cluster集成了哨兵的功能,能自动进行故障转移。
• 面试常问：
  • 为什么是16384个槽？ （参考答案：这是一个权衡的结果，槽数太少，数据分布会不均衡；槽数太多，节点间同步槽位信息的心跳数据包会太大，浪费网络带宽，作者经过测算认为16384是个比较合适的值。）
  • 如果我想新增一个节点，扩容怎么做？ （参考答案：需要用到redis-trib.rb工具或相关命令进行“重新分片”，这个过程是逐步的，会把现有某些节点上的一部分槽位和数据迁移到新节点上，在迁移过程中，客户端请求的key如果还在老节点，就直接处理；如果已经迁到新节点，老节点会返回一个“重定向”错误，告诉客户端去正确的节点访问。）
  • Redis Cluster的优缺点？ （参考答案：优点：1. 支持海量数据存储，可以水平扩容，2. 具备高可用和自动故障转移能力，缺点：1. 架构复杂，部署和维护成本高，2. 不支持跨多个key的事务（因为key可能分布在不同的节点上），3. 客户端实现更复杂，需要支持重定向。）

总结与对比

面试官最后可能会让你对比一下这几种模式：

• 主从复制：基础备份和读写分离，但不高可用。
• 哨兵模式：在主从基础上实现了高可用,适合数据量不是特别大的场景。
• Redis Cluster：在哨兵基础上增加了分片功能，适合海量数据和高并发的场景,是终极方案。

把这三者的关系和演进逻辑讲清楚，面试官基本就会认为你对Redis高可用有了比较扎实的理解了，关键不是死记硬背命令，而是理解每种方案要解决什么问题，以及它们各自的 trade-off（权衡）。