offerEngine

📖 版块 A：知识讲解版 (温故知新)

Redis 要走向生产环境，单机是绝对不行的（单点故障、容量受限）。为此，Redis 提供了三种高可用演进架构：

1. 主从复制（Master-Slave）：

   • 原理：一台 Master 负责写，多台 Slave 负责读。Slave 启动时向 Master 发送 PSYNC，进行全量同步（RDB 文件）或增量同步（基于 repl_backlog_buffer）。
   • 优点：实现了读写分离，提高了读并发能力，并做到了数据备份。
   • 致命缺点：不具备自动容灾能力。Master 挂了，需要人工干预去把 Slave 提拔为 Master，这期间服务不可用。

2. 哨兵模式（Sentinel）：

   • 原理：为了弥补主从复制无法自动容灾的缺陷，引入了哨兵集群。哨兵是一个特殊的 Redis 节点，它不存业务数据，只负责干三件事：监控、选主、通知。
   • 工作流程：哨兵通过心跳检测判断 Master 是否下线（主观下线 -> 客观下线）。确认 Master 挂了后，哨兵集群内部通过 Raft 算法 选举出一个哨兵 Leader，由这个 Leader 负责从 Slave 中挑一个最优秀的（看优先级、复制进度、RunID）晋升为新 Master，并把最新的架构通知给客户端。
   • 优点：实现了自动故障转移（Failover），保证了高可用。
   • 致命缺点：无法解决海量数据存储和超高写并发问题。无论怎么加节点，始终只有一个 Master 能写，且每个节点都必须存全量数据，受到单机内存的物理限制。

3. 切片集群模式（Redis Cluster）：

   • 原理：Redis 3.0 官方推出的分布式解决方案。它采用**哈希槽（Hash Slot）**机制，将所有数据划分为 16384 个槽位，均匀分配给多个 Master 节点。每个 Master 节点各自带几个 Slave 节点。
   • 去中心化通信：节点之间通过 Gossip 协议（Ping/Pong/Meet/Fail）交换状态信息，实现了无中心节点的高可用。当有节点故障时，集群自己就能完成类似哨兵的故障转移。
   • 优点：既实现了自动高可用，又实现了数据分片，突破了单机内存的限制，可以横向无限扩展（Scale Out）写并发和存储容量。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：讲讲 Redis 的高可用架构吧，主从、哨兵和 Cluster 集群分别解决了什么问题？有什么区别？

💬 高手逐字稿：

Redis 的高可用架构演进，其实是一部“不断解决上一代痛点”的发展史。

最开始，单机 Redis 面临单点故障和读并发瓶颈。于是引入了主从复制架构，也就是“一主多从”。主库负责写，从库负责读。这解决了数据备份和读并发的问题。但它有一个致命缺陷：** 没有自动容灾能力**。主库一挂，半夜还得人工起床去敲命令切换主库。

为了解决这个“人工干预”的痛点，哨兵（Sentinel）架构诞生了。 哨兵其实就是一个独立的监控集群，它的核心职责就是三件事：监控、选主和通知。当哨兵通过心跳发现 Master 挂了后，会在内部利用 Raft 分布式共识协议选举出一个哨兵 Leader，由它来主持大局，从剩下的从库里挑选一个数据最新、优先级最高的晋升为新主库，并通知客户端。哨兵架构完美解决了自动故障转移的问题，是很多中小型互联网公司的标配。

但随着业务发展，哨兵架构又暴露出了新的天花板。因为在哨兵模式下，无论你挂多少个从库，能执行写操作的始终只有一个 Master，而且每个节点都必须装载整个业务的全量数据。一旦总数据量超过了几十个 G，单机的物理内存和主库的写性能就扛不住了。

为了突破“单机容量和写并发”的瓶颈，最终演进出了 Redis Cluster（切片集群）。 它是真正的分布式解决方案。它最大的特点是引入了**哈希槽（Hash Slot）**的概念，把数据硬切成了 16384 份，平摊给多个 Master 节点。这就意味着，我们可以横向无限扩展主库的数量来提升存储上限和写性能。

同时，Redis Cluster 不需要单独的哨兵来监控了，它是去中心化的。节点之间通过 Gossip 协议不断地发 Ping/Pong 消息交换状态，一旦发现某个主库挂了，集群内的其他主库会自动完成故障发现和选主转移。

所以总结来说：主从复制解决了读并发，哨兵解决了自动高可用，而 Cluster 集群则在兼顾高可用的同时，终极解决了海量数据存储和写并发的扩容问题。