Redis集群架构怎么帮存储能力飞起来，聊聊那些提升的门道

说到Redis集群怎么让存储能力“飞起来”，咱们可以把它想象成一家生意爆好的餐厅，最开始只有一个小厨房（单机Redis），一个厨师（CPU）忙前忙后，地方（内存）就那么大，来的客人（数据）一多，不仅菜做得慢，连放食材的地方都不够了，这时候，老板决定搞个大事情——开连锁店，也就是搭建Redis集群，这门道，主要就在“分”和“高可用”这两个词上。

第一大门道：数据分片，把大仓库变成连锁店

单机Redis的内存再大也是有上限的，就像一个小仓库总有装满的时候，Redis集群最核心的本事就是“数据分片”，它不再把所有鸡蛋（数据）都放在一个篮子里，而是准备了很多个篮子（在Redis集群里叫“分片”或“实例”）。

那具体怎么分呢？它用一个很巧妙的方法：给每个数据一个“身份证号”，也就是通过一个哈希函数算出一个哈希槽的编号，Redis集群预先规划了16384个这样的槽位（可以想象成16384个固定的储物格）,然后把这些槽位相对均匀地分配给集群里的每一个Redis实例。

一个三主三从的集群，可能把0-5460号槽位分给实例A，5461-10922号分给实例B，10923-16383号分给实例C，当你存一个数据时，集群会根据key计算它属于哪个槽，然后直接把它存到管理这个槽的对应实例上，这样一来，原本需要一个超级大的仓库才能装下的数据，现在被分散到了三个（或者更多）小仓库里，存储容量自然就成倍增加了，这就好比把一家大餐厅的业务，分给了三家连锁店共同承担，每家店只需要负责一部分客人的订单，存储和处理的压力就小多了。（这个分片和哈希槽的设计思想,在Redis官方的集群规范文档中有详细定义）

第二大门道：高可用与扩容，连锁店不怕厨师请假或开新店

光有分片还不够，万一某个实例宕机了，就像连锁店里有个厨师突然请假了，那他负责的那部分菜不就没人做了吗？数据也就丢失了，Redis集群给每个主实例（主节点）都配了至少一个备用实例（从节点）。

平时，主节点负责写和读，从节点默默地同步主节点的数据，相当于副厨在跟着主厨学手艺，一旦主节点宕机，集群就会自动检测到，并迅速推举一个对应的从节点“转正”成为新的主节点，继续提供服务，这个过程是自动的，对前来访问的应用程序来说，可能只是感觉网络稍微卡顿了一下，但数据不会丢，服务也很快恢复了，这就保证了存储服务的稳定性和可靠性，让存储能力能持续地“飞”，而不是飞一会儿就掉下来。（这种主从复制和故障自动切换的机制,是Redis集群实现高可用的核心）

当业务增长，觉得存储空间又不够用了怎么办？扩容就很简单，这就好比餐厅生意太好，决定开第四家连锁店，你只需要把新的Redis实例加入到集群中，集群会自动地、一点点地从现有的各个实例上迁移一部分哈希槽到新实例上，这个迁移过程是在线进行的，期间集群依然可以正常提供服务，应用程序几乎无感知，缩容也是同样的道理，反向操作即可，这种弹性伸缩的能力，让存储能力可以随着需求平滑地“飞”得更高。

第三大门道：客户端的门道，得有个聪明的导航系统

有了连锁店，还得有个好用的导航APP，不然客人找不到哪家店能处理自己的订单，在Redis集群里，这个“导航”角色很大程度上由客户端来承担。

一个支持集群的智能客户端，会在启动时就获取整个集群的“地图”——也就是每个实例分别管理哪些哈希槽，当应用程序要读写一个key时，智能客户端会先自己算出这个key属于哪个哈希槽，然后根据“地图”直接连接到正确的目标实例进行操作，避免了每次都去问路由信息,效率非常高。

也有特殊情况，比如集群正在扩容迁移数据，一个key可能还在原实例上，也可能已经迁到了新实例上，如果客户端连错了地方，对方实例会告诉它“这个key不归我管了，你现在应该去某某实例那儿找”，并返回正确的地址，客户端收到这个“重定向”指令后，就会去正确的实例获取数据，并更新自己的“地图”，这个聪明的交互过程，确保了即使在变动中，数据访问也能准确无误。（客户端与集群的这种智能交互行为，在Redis的协议中被称为“MOVED”和“ASK”重定向）

总结一下

Redis集群让存储能力飞起来的门道，归根结底是：通过数据分片解决了单机容量瓶颈，实现了横向扩展；通过主从复制和故障自动切换解决了单点故障问题，实现了高可用性；再结合智能客户端和重定向机制，保证了在分布式环境下数据访问的正确性和效率，这几招组合起来，就让Redis从一个单打独斗的“小厨房”，变成了一个能抗能打、弹性伸缩的“连锁餐饮集团”,存储能力和服务可靠性自然就实现了质的飞跃。