Redis架构从单机到集群的变化，聊聊那些年它的发展故事

说到Redis的发展故事，就像看一个技术产品的成长日记，特别有意思，它从一个简单的小工具，慢慢演变成了现在能支撑海量数据的大系统，这一切的变化，核心都围绕着如何解决一个问题：当数据越来越多，访问压力越来越大,单个Redis实例顶不住了怎么办？

第一阶段：单机时代，简单就是美

最早的时候，Redis就是个单机版的软件（根据Redis官方文档对早期版本的描述），你把它安装在一台服务器上，所有的数据都存放在这台机器的内存里，读写请求也都由这一个实例来处理，这种方式特别简单，部署容易，理解起来也不费劲，在数据量不大、访问量不高的初期阶段,这完全够用了。

但单机有个明显的天花板：内存是有限的，一台服务器的内存再大，也有装满的时候，万一这台服务器硬盘坏了或者宕机了，整个Redis服务就不可用了，数据也可能丢失，为了解决这些问题，Redis的创造者Salvatore Sanfilippo（别名antirez）和社区开始为Redis寻找“外援”。

第二阶段：主从复制，找个“备胎”

主从复制（Replication）功能被引入了（根据《Redis设计与实现》一书中的描述），这可以看作是Redis迈向分布式的第一步，它的想法很直观：既然一台机器不保险，那就再准备一台或多台机器作为“副本”（Slave）。

主节点（Master）负责处理所有的写操作，然后把这些操作实时地同步给一个或多个从节点（Slave），从节点就像主节点的影子，数据几乎和主节点一模一样,这样做带来了两大好处：

1. 数据备份和高可用：如果主节点宕机了，可以手动把一个从节点“扶正”成为新的主节点，让服务尽快恢复,数据也不至于全丢。
2. 读写分离：读请求可以分流到从节点上去处理，减轻主节点的压力,适合读多写少的场景。

但这个阶段还不够自动化，主节点挂了，需要人工干预来切换，故障恢复不够快，写操作的压力依然全部集中在那一个主节点上,瓶颈问题没有根本解决。

第三阶段：哨兵模式，引入“自动管家”

为了解决主从复制需要人工干预的问题，Redis 2.8版本引入了哨兵（Sentinel）系统（根据Redis官方博客对Sentinel的发布介绍），哨兵是一个独立的进程，你可以部署多个哨兵实例来组成一个集群，它们共同监控主节点和从节点是否在“健康工作”。

哨兵就像一群尽职尽责的管家，7x24小时地盯着Redis主从节点，一旦发现主节点“失联”了，多个哨兵会通过投票机制达成一致，然后自动执行故障转移：挑选一个健康的从节点，将其升级为新的主节点，并通知其他的从节点和客户端这个变化，这样一来，高可用性得到了极大的提升，服务可以做到自动切换,几乎无需人工介入。

哨兵模式依然没有解决根本的瓶颈：所有数据还是存在一个主节点上，写能力和存储容量受限于单台机器的性能，要想突破这个限制，必须对数据本身“动刀”,也就是把数据分开放。

第四阶段：集群化分片，真正的分布式时代

这才是解决海量数据问题的终极方案，也就是我们现在常说的Redis Cluster，它在Redis 3.0版本中正式推出（根据Redis官方对Redis 3.0的发布说明），它的核心思想是“分片”（Sharding）。

Redis Cluster把整个数据集自动划分成16384个哈希槽（Hash Slot），你可以组建一个由多个主节点组成的集群，每个主节点负责一部分哈希槽，比如一个三主节点的集群，可能分别负责0-5460、5461-10922、10923-16383号槽位。

当客户端要存储或读取一个数据时，会先用CRC16算法计算键（Key）的哈希值，再对16384取模，找到这个键对应的槽位，然后直接连接到管理这个槽位的节点上进行操作，这样,写压力和存储空间就随着主节点的增加而线性增长了。

Redis Cluster的每个主节点都可以配备一个或多个从节点，实现了数据冗余和故障自动转移，兼具了高可用和可扩展性,它标志着Redis真正成为了一个成熟的分布式内存数据库。

总结一下这个故事线

Redis的架构演变,是一个典型的因需求而驱动的进化过程：

• 单机版：解决“从无到有”的问题,追求极致的简单和性能。
• 主从复制：解决“数据备份”和“读压力”问题,但故障需手动处理。
• 哨兵模式：解决“高可用自动化”问题，让服务更稳定,但写瓶颈仍在。
• Redis Cluster：解决“海量数据和超高并发”问题，通过分片实现水平扩展,成为企业级应用的基石。

这个发展历程，不仅反映了Redis本身技术的成熟，也映射了整个互联网业务数据量爆炸式增长的时代背景，直到今天，根据不同的业务场景和规模,这几种架构模式依然各有其用武之地。