从单点到集群：Redis 分布式缓存的演进之路

在分布式系统的架构中，缓存几乎是绕不开的一环。而Redis，凭借其高性能、丰富的数据结构和多样的部署模式，成为了缓存领域的绝对王者。但很多同学刚接触Redis时，可能只停留在set/get的使用层面，对它从“单点单机”到“分布式集群”的演进过程一知半解。

今天，我就带着大家顺着「单点Redis → 持久化 → 主从复制 → 哨兵模式 → 分片集群」这条线，聊聊Redis是如何一步步解决高可用、高性能、可扩展三大难题的，也算是对自己这段时间学习Redis的一个总结。

一、单点Redis：看似简单，却隐患重重

刚接触Redis时，我们最先接触的就是“单点部署”——一个Redis实例，服务直接连接它读写数据。这种模式开发简单、部署方便，但在生产环境中却隐患重重：

性能瓶颈
Redis核心逻辑是单线程的，单节点的处理能力有明确上限，面对高并发的读/写请求，很容易成为系统的瓶颈；同时单节点的内存也有限，无法存储海量的缓存数据。
可靠性灾难
这是更致命的问题。如果这个唯一的Redis节点挂了（比如进程崩溃、服务器宕机），会直接导致缓存失效，请求全部打到数据库，引发“缓存雪崩”，直接把数据库压垮；更严重的是，如果没有数据备份，节点挂了之后数据直接丢失，造成不可逆的损失。
运维痛点
单点Redis的扩容、维护都很麻烦，一旦需要升级或者重启，整个服务的缓存都不可用了。

所以，我们需要给Redis加上“保险”和“分身”，首先解决的就是数据不丢失的问题——也就是Redis持久化。

二、Redis持久化：给数据上一道“保险”

持久化，说白了就是把Redis的内存数据，写到硬盘上保存下来，这样就算Redis挂了，重启的时候也能从硬盘把数据恢复回来，解决数据丢失的问题。Redis提供了两种持久化方案，各有优劣：

1. RDB（Redis Database）：定时的“全量快照”

原理：按照配置的规则（比如save 60 1000，表示60秒内有1000次修改就触发），定时把Redis的全量数据生成一个快照文件.rdb，保存到硬盘。
优点：恢复速度快，适合做冷备份；对Redis主线程影响小（由fork出的子进程完成快照生成）。
缺点：可能丢数据，两次快照之间的数据如果Redis挂了，这部分修改就会丢失；如果数据量很大，fork子进程会占用较多内存，生成RDB文件也会有一定的IO开销。

2. AOF（Append Only File）：实时的“操作日志”

原理：把Redis收到的每一条写命令，都追加写入到.aof文件里。Redis重启的时候，会重新执行一遍AOF里的命令，恢复数据。
优点：数据更安全，支持每秒同步、每次写同步等策略，最多只丢1秒的数据；AOF文件是可读的，遇到问题可以手动修改。
缺点：文件体积比RDB大，恢复速度比RDB慢；高并发下频繁刷盘会带来IO压力。

在实际生产中，很多时候我们会同时开启RDB和AOF，用AOF保证数据不丢，用RDB做快速恢复和冷备份。但持久化解决了数据不丢的问题，却没解决“服务挂了就不可用”的问题——主节点挂了，就算有RDB/AOF，恢复也需要时间，这段时间服务还是不可用的。而且读写都压在一个节点上，性能瓶颈还是没解决。于是，主从复制就来了。

三、Redis主从复制：读写分离，给主节点找个“帮手”

主从复制，就是搭建一个主节点（Master）和多个从节点（Slave/Replica），主节点负责处理写请求，同时把数据同步给所有从节点；从节点只负责处理读请求，不处理写请求。

核心作用

读写分离，分担读压力：大部分业务场景都是读多写少，把读请求打到从节点，能大幅提升Redis的整体读性能。
数据备份：从节点实时同步主节点的数据，相当于多了几份热备份，就算主节点挂了，从节点也有完整的数据。

工作原理

从节点启动后，发送SYNC命令给主节点，主节点会fork一个子进程，生成RDB快照发给从节点，同时把快照期间的写命令缓存起来发给从节点；从节点先加载RDB文件，再执行缓存的命令，完成全量同步。之后主节点收到的写命令，都会实时同步给从节点，实现增量同步。

但主从复制有个致命的问题：故障无法自动转移。如果主节点挂了，从节点不会自动变成新的主节点，需要人工手动操作，把一个从节点提升为主节点，然后修改客户端的配置，把写请求切过去。在高可用的场景下，人工操作太慢了，这段时间服务还是写不可用的。而且，主节点的写性能瓶颈还是没解决，所有写请求都要打到主节点，当写并发很高的时候，主节点还是会扛不住。

为了解决自动故障转移的问题，Redis推出了哨兵模式。

四、Redis哨兵模式：自动“故障管家”，实现高可用

哨兵（Sentinel）本质上是一个监控程序，它的核心目标就是实现主从集群的自动故障转移，让Redis在主节点挂了的时候，能自动选一个从节点升级为新的主节点，保证服务持续可用。

哨兵的核心能力

监控：哨兵会定期和主节点、从节点通信，检查它们是否正常运行。
自动故障转移：如果哨兵判定主节点“主观下线”，并且多个哨兵协商后判定为“客观下线”，就会从从节点中选一个优先级最高的，把它升级为新的主节点，然后通知其他从节点去复制新的主节点。
配置通知：哨兵会把新的主节点信息通知给客户端，让客户端自动切换写请求的地址。

为了避免哨兵自己单点故障，哨兵通常会部署成集群模式，多个哨兵互相监控，通过投票机制来决定主节点的状态，防止误判。

哨兵模式解决了主从集群的自动故障转移问题，实现了Redis的高可用。但它还是有局限：写操作和数据存储的瓶颈依然存在。整个哨兵集群里，还是只有一个主节点负责写请求，当业务的写并发很高，或者缓存数据量超过单节点的内存上限时，哨兵模式还是扛不住。这时候，就轮到Redis分片集群登场了。

五、Redis分片集群：横向扩展，突破性能与存储上限

Redis分片集群（Redis Cluster）是Redis官方提供的分布式解决方案，它的核心思路是把数据分散存储到多个主节点上，每个主节点只负责一部分数据的读写，从而实现横向扩展。

核心原理

哈希槽（Hash Slot）：Redis Cluster把整个数据库分成了16384个哈希槽，每个主节点负责其中一部分槽位（比如节点A负责0-5000，节点B负责5001-10000，节点C负责10001-16383）。
数据分片：当客户端写数据的时候，会对key做CRC16哈希运算，然后对16384取模，得到对应的哈希槽，然后把请求发到负责这个槽的主节点上。
主从分片：每个主节点都可以配置对应的从节点，实现故障转移，保证高可用。
节点间通信：集群内的节点通过Gossip协议互相通信，维护集群的状态，客户端可以连接任意一个节点，就能获取到整个集群的路由信息。

分片集群完美解决了哨兵模式的两个痛点：