Redis怎么做到既高可用又能扛住大流量的那些事儿

Redis怎么做到既高可用又能扛住大流量的那些事儿，咱们就聊聊它背后的几种看家本领，这些方法都不是凭空想出来的，而是人们在实践中为了应对不同的问题,一步步摸索出来的。

主从复制：找个靠谱的“备胎”

最开始，大家想，万一唯一的一台Redis服务器（这叫主服务器）宕机了，那整个服务不就全挂了吗？这太不可靠了，于是就有了主从复制这个最基础的法子。（来源：Redis官方文档关于复制的介绍）

这就像给主服务器请了几个“跟班”或者说“备胎”，你设定一台是主服务器（Master），负责主要的读写操作，然后再设置一台或多台从服务器（Slave），主服务器会把自己收到的所有能改变数据状态的命令（比如set、del这些），实时地、不断地同步给从服务器，这样，从服务器上的数据几乎和主服务器一模一样,成了它的一个完整副本。

这样做的好处很明显：

1. 数据备份：即使主服务器突然坏了，从服务器上还有一份完整的数据,不会全部丢失。
2. 读写分离：读的请求量通常远大于写的请求量，我们可以让主服务器只处理写请求，而把大量的读请求分散到各个从服务器上去,这样就相当于多了好几个帮手来扛住读流量的压力。

但这个方法有个致命伤：主服务器只有一个，它要是宕机了，虽然数据还在从服务器那里，但没人能接收写请求了，整个系统对外还是“半瘫痪”状态,高可用性还不够。

哨兵模式：引入一个“自动管家”

为了解决主服务器宕机后需要人工干预的麻烦，Redis引入了哨兵（Sentinel）模式。（来源：Redis官方文档关于Sentinel的介绍）

哨兵本身不是一个存储数据的服务器，而是一个或多个独立的、专门负责“盯梢”的进程，这些哨兵进程会不间断地监控所有Redis服务器（包括主服务器和从服务器）的健康状况，就像个“自动管家”。

它的核心本领是：

1. 监控：哨兵会定期检查主从服务器是否还“活着”。
2. 自动故障转移：一旦哨兵们通过投票发现主服务器确实宕机了，它们就会自动从剩下的从服务器中，投票选出一个新的主服务器，然后告诉其他的从服务器：“以后就听这位新大哥的！”也会通知连接Redis的客户端（比如你的应用程序），主服务器已经换人了,让客户端去连接新的主服务器。

这样一来，整个系统就实现了自动化的高可用，主服务器挂了，几乎不需要人工参与，系统就能在几十秒内自己恢复正常的读写服务,哨兵模式让Redis集群的可靠性大大提升。

无论是主从复制还是哨兵模式，它们都有一个瓶颈：所有的服务器都存着全量的数据，当你的数据量非常大，一台机器的内存根本装不下的时候，或者写操作的量巨大，一台主服务器根本处理不过来的时候,这两个模式就无能为力了。

集群模式：化整为零，大家分着干

为了应对海量数据和高并发写的挑战，Redis最终祭出了大招——集群（Cluster）模式。（来源：Redis官方文档关于Cluster的介绍）

集群模式的思想很简单，分片”（Sharding），我不再把所有数据都存在一起，而是把数据分成很多份，每一份数据分配到一个“主从服务器小组”里去存储，一个Redis集群由很多个这样的“小组”组成。

举个例子，假如我有1个亿的键值对数据，我可以把它们分散到5个主从小组里，每个小组只负责存储和管理大约2千万条数据,这样：

1. 扛住大流量：写请求也被分散到了5个主服务器上，写的能力提升了5倍，读请求可以分散到所有主服务器和它们的从服务器上，读的能力更是成倍增长,这就解决了单台机器性能瓶颈的问题。
2. 高可用依旧：在每个小组内部，依然是主从复制+哨兵类似的机制（集群自身实现了故障转移功能），也就是说，小组里的主服务器挂了，它会自动在小组内选一个从服务器顶上去，只要不是某个数据分片的所有主从服务器同时挂掉,整个集群就能继续提供服务。

集群模式更复杂，它需要客户端支持，能够知道该去连接集群中的哪个节点来找到想要的数据,但它是Redis能够同时实现高可用和支撑极高流量的终极方案。

总结一下

所以你看,Redis就是这么一步步进化过来的：

• 先用主从复制解决数据备份和读流量压力的问题。
• 再用哨兵模式解决主服务器宕机后自动切换的难题,实现高可用。
• 最后用集群模式通过数据分片，彻底打破单机内存和性能的限制,同时继承了高可用的能力。

这三种方式可以根据你业务的需求和规模，单独使用或者组合使用，让Redis在各种复杂的场景下，既能坚如磐石,又能吞吐自如。