单节点的天花板在哪

Redis 快是因为数据全在内存，但单台机器的内存和带宽都有限。当缓存数据量涨到几十 GB、并发读写压到单机极限，就需要走向高可用与水平扩展。Redis 的进阶路线是一条清晰的台阶：主从复制 → 哨兵自动切换 → Cluster 分片集群，按业务规模逐级上。

注意：缓存场景下 Redis 挂了不代表系统崩（可以回源数据库），但持久化场景（当数据库用）挂了就丢数据，对可用性和持久化的要求完全不同，选型时要先分清你的 Redis 是缓存还是存储。

本文核心知识点
  • 主从一主多从，读请求分摊到从节点。
  • 哨兵监控主节点、故障时自动提升从为主。
  • Cluster数据按槽分片，多主多从水平扩展。
  • 持久化RDB 快但可能丢、AOF 安全但文件大。
Redis 集群配图：蓝色渐变背景上多个发光缓存方块节点围成环形拓扑，箭头在节点间流动，右下角磁盘圆柱表示持久化
环形节点代表 Cluster 分片集群，磁盘圆柱代表持久化。

主从复制与读写分离

主节点负责写，从节点异步复制主节点的数据、负责读。这样读多写少的场景（比如缓存）就能把读压力分摊到多台从库。要接受一个事实：复制是异步的，主写完立刻返回，从还没同步完时就可能读到旧数据——缓存场景无所谓，强一致场景要留意。

哨兵：自动故障转移

主从结构的问题是主节点挂了谁来当主。哨兵（Sentinel）是一组独立进程，监控主从节点，发现主挂了就自动从从库里选一个提升为新主，并通知客户端切换。这样主节点故障无需人工介入，几秒内自动恢复。适合数据量还不大、单主就能扛住、主要追求高可用的场景。

Cluster：分片与水平扩展

当单主内存或写能力到顶，就要用 Cluster：数据被分到 16384 个槽，每个主节点负责一部分槽，每个主又挂从节点做备份。客户端通过槽位路由直接连到正确的节点，天然水平扩展。代价是跨槽的多键操作（如多键事务、批量）受限，业务设计时要把相关数据落到同一槽（用 hash tag）。

// 用 hash tag 让两个 key 落到同一槽，支持多键操作
// {} 内的部分决定槽位
user:{1001}:name
user:{1001}:age

持久化：RDB 与 AOF 的取舍

Redis 有两种持久化方式。RDB 是定期把内存快照写成二进制文件，恢复快、文件小，但两次快照之间宕机会丢数据。AOF 是把每条写命令追加到日志，丢得少（可配每秒刷盘），但文件大、恢复慢。生产上常两者同开：AOF 保证数据安全、RDB 做快速恢复的兜底。纯缓存场景甚至可以关持久化，反正重启后回源即可。

缓存策略与数据一致性

缓存和数据库之间的一致性是经典难题。主流做法是旁路缓存（Cache Aside）：读时先查缓存、没有再查库并回填；写时先更新数据库、再删除缓存（不是更新缓存）。删除而非更新是为了避免并发写导致脏缓存。配合过期时间兜底，能把不一致窗口压到很短。