单机模式这是最基础的架构只有一个 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 AMaster A 检查发现这个槽位现在已经移交给 Master B 了。于是拒绝执行并向客户端返回一个特殊的错误信息意思找错啦槽位 1234 现在在 Master B 呢客户端 收到 MOVED 错误后会自动去连接 Master B 重新发送请求同时在本地暗中更新自己的集群地图缓存确保下一次直接找对人。架构对比与选型建议架构类型自动故障转移横向扩展分片适用场景单机模式否否个人开发测试、本地缓存、对可用性要求极低的非核心业务。主从复制否否读多写少、数据量小但允许人工手动恢复故障的场景。哨兵模式主节点自动切换否中小型企业首选。数据量不大如几十 GB 以内但对稳定性、高可用要求极高。集群模式自动切换具有横向扩展能力海量数据、超高并发首选。数据量超百 GB或写并发极高的核心业务。