Redis实战：Redis架构

单机模式

这是最基础的架构，只有一个 Redis 实例负责所有的读写操作。

工作原理： 所有客户端都直接连接这一个实例，数据完全存储在该实例的内存中。

优点： 架构最简单，部署和维护成本极低，性能在单机瓶颈内是最高的（没有网络同步开销）。

缺点：

• 存在单点故障： 一旦宕机，整个缓存/数据库服务直接瘫痪。
• 容量有限： 内存容量受限于单台服务器的物理内存

主从复制模式

为了解决单机模式的读写压力和数据备份问题，引入了主从架构。

工作原理： 包含一个主节点（Master）和多个从节点（Slave）。

• 主节点负责处理写操作，并将数据异步同步给从节点。
• 从节点只负责处理读操作，实现读写分离。

优点： 极大提高了系统的读并发能力；从节点作为数据备份，提高了数据安全性。

缺点：

• 无法自动故障转移： 如果主节点挂了，系统无法自动把从节点升级为新主节点，需要人工干预（修改配置、重启）。
• 写瓶颈与容量限制： 写操作和数据存储依然受限于单台主节点的上限。

哨兵模式

哨兵模式是在主从复制的基础上，加入了自动化的高可用（HA）解决方案。

工作原理： 引入了独立的“哨兵（Sentinel）”集群（通常由 3 个或更多奇数个哨兵节点组成）。哨兵不存储业务数据，它们只负责做三件事：

• 监控： 周期性地检查主从节点是否正常运行。
• 自动故障转移： 当发现主节点宕机时，哨兵集群会通过投票选举出一个从节点，自动将其升级为新的主节点。
• 通知： 将新主节点的地址通知给客户端。

优点： 真正实现了高可用，主节点宕机时可以做到秒级自动切换，无需人工介入。

缺点： 数据依旧是全量存储在单台机器上，无法解决单机内存容量瓶颈和写操作瓶颈。

集群模式

Redis 3.0 正式推出的分布式解决方案，是目前大型互联网企业最主流的架构，彻底解决了容量和写性能的瓶颈

工作原理： 采用无中心化的分布式架构，将数据分散存储在多个不同的 Redis 节点上。

• 它将数据空间划分为 16384 个哈希槽。
• 每个主节点负责其中一部分槽位。
• 为了保证高可用，Cluster 中的每个主节点通常都会配置一个或多个从节点，当某个主节点挂了，集群内部会自动将对应的从节点升级。

优点：

• 水平扩展： 数据分片存储，支持在线动态扩容/缩容，理论上可以无限扩展内存和并发能力。
• 内置高可用： 无需额外搭建哨兵集群，自身就具备故障自动转移能力。

缺点：

• 架构和配置相对复杂。
• 对批量操作（如 MGET、MSET）有限制，只有当多个 Key 映射到同一个哈希槽时才能正常执行

故障转移

在 Redis 集群中，故障转移是全自动执行的，不需要像“哨兵模式”那样依赖额外的哨兵节点。Redis 集群的故障转移主要依赖于节点之间的 Gossip 协议（心跳机制）、多数派投票共识 以及 从节点的自主竞争。

在集群模式下，客户端会和多个 Master 节点建立连接

现代的 Redis 智能客户端（如 Java 的 Jedis/Lettuce）在初始化连接集群时，其内部运行机制如下：

握手与缓存拓扑： 客户端启动时，只需配置集群中任意一个节点的 IP 和端口。连接上该节点后，客户端会发送 CLUSTER NODES 或 CLUSTER SLOTS 命令

获取全局地图： 节点会把整个集群的“地图”（即哪个 Master 负责哪些哈希槽，以及它们的 IP 和端口）完整返回给客户端

建立连接池： 客户端收到地图后，会在后台自动与所有的 Master 节点分别建立连接池并保持长连接

客户端是如何精准发送请求的？

当你在代码中执行一条命令时，比如 SET user:123 "tom"：

本地计算槽位： 客户端在本地使用 CRC16 算法计算出 user:123 这个 Key 属于哪个哈希槽（Slot）。

直达目标机器： 客户端查找本地缓存的集群地图，发现这个槽位归 Master B 管，于是它会直接从与 Master B 建立的连接池中取出一个连接，把写请求发送过去。整个过程是一步到位的，不需要经过任何中间代理（Proxy）转手

如果客户端找错人怎么办？（MOVED 重定向）

如果集群的槽位发生了动态迁移（比如运维人员刚刚进行了扩容或缩容），而客户端本地的地图还没来得及更新，就会发生“找错人”的情况：

客户端： 以为 user:123 在 Master A，于是把请求发给了 Master A

Master A： 检查发现这个槽位现在已经移交给 Master B 了。于是拒绝执行，并向客户端返回一个特殊的错误信息（意思：找错啦！槽位 1234 现在在 Master B 呢）

客户端： 收到 MOVED 错误后，会自动去连接 Master B 重新发送请求，同时在本地暗中更新自己的集群地图缓存，确保下一次直接找对人。

架构对比与选型建议

架构类型	自动故障转移	横向扩展（分片）	适用场景
单机模式	否	否	个人开发测试、本地缓存、对可用性要求极低的非核心业务。
主从复制	否	否	读多写少、数据量小，但允许人工手动恢复故障的场景。
哨兵模式	主节点自动切换	否	中小型企业首选。数据量不大（如几十 GB 以内），但对稳定性、高可用要求极高。
集群模式	自动切换	具有横向扩展能力	海量数据、超高并发首选。数据量超百 GB，或写并发极高的核心业务。