Redis集群扩容那些事儿，聊聊方案和实际操作中遇到的坑

主要综合自个人实践经验、社区论坛讨论如掘金、CSDN上的技术分享,以及Redis官方文档的实践部分）

聊起Redis集群扩容，这事儿说白了就跟咱们家里东西越来越多，得换个更大的房子或者多租个房间是一个道理，Redis最开始可能就搭了三个节点，数据少，访问量也小，相安无事，但随着业务像吹气球一样涨起来，原来的“小房子”就挤不下了，要么是存储空间告急，要么是处理请求的速度变慢，这时候,你就不得不考虑扩容了。

目前最主流的方案，就是基于Redis Cluster的扩容，它就像个已经规划好小区楼栋的社区，数据被分成16384个槽位（slots），均匀分给现有的那些主节点，扩容的本质，就是找来新的服务器，启动新的Redis实例作为新节点，然后从原来那些“老住户”（现有节点）手里,匀一部分槽位和数据搬过来给新节点管理。

常见的扩容方案步骤，说起来简单，但做起来得小心翼翼：

1. 准备新节点：这步算是最省心的，就是找好几台干净的服务器，把Redis软件装好，配置文件里指明它是集群的一部分，然后启动起来，这时候它还是个“光杆司令”,没管任何数据。
2. 加入集群：用专门的集群命令，把这个新节点介绍给现有的集群老大（任意一个现有节点认识就行），集群知道了有新伙伴加入,但还没给它分活儿。
3. 迁移槽位和数据：这是整个扩容过程中最核心、最耗时也最容易出幺蛾子的环节，你不能一下子把所有要挪的槽位都搬过去，那样集群可能就懵了，得一个一个槽位来，或者一小批一小批地迁移，操作上，通常是告诉集群：“把某某槽位从现在管的A节点，交给新来的B节点管。” 集群自己就会在后台忙活起来，把这个槽位里的数据一点点地从A同步到B，在迁移过程中，对于正在搬家的那个槽位，如果客户端有请求过来，A节点如果发现自己还有这个数据，就自己处理；如果发现已经搬走了，就会给客户端一个“重定向”提示，告诉它：“这个数据现在归B管了，你去找它。” 客户端聪明的话，就会自动去找B节点要数据，这也就是所谓的“ASK重定向”。
4. 确认与平衡：等所有计划要迁移的槽位都搬完了，需要检查一下是不是每个槽位都有主了，并且数据是不是都匀得差不多了，有时候可能还需要微调一下，让各个节点负责的槽位数量更均衡，避免出现“旱的旱死，涝的涝死”。

实际操作中遇到的坑，那才叫一个精彩：

• 坑一：网络带宽被打满，业务喊卡，这是最常碰到的，数据迁移本质上是网络传输，如果一下迁移太多槽位，或者单个槽位里数据量巨大（比如有几个特大号的Key），迁移进程就会像脱缰的野马，疯狂占用服务器之间的网络带宽，这可能会挤占正常业务请求的网络资源，导致业务响应延迟飙升，甚至超时，迁移时必须“温柔”，要控制迁移的速度和批次，最好在业务低峰期进行,并且时刻监控网络流量。
• 坑二：客户端愣头青，不懂重定向，上面提到的ASK重定向机制，需要Redis客户端库的支持，如果你用的客户端库版本太老或者实现得不好，它可能看不懂集群返回的“重定向”指令，导致迁移过程中部分请求失败,扩容前务必检查并升级所有业务线使用的Redis客户端到兼容Cluster的稳定版本。
• 坑三：大Key迁移要老命，如果一个Hash或者ZSET里面塞了几百万个元素，迁移这种大Key时，节点可能会“卡住”很长时间去序列化和传输这单个Key，期间不仅影响该节点的性能，还可能因为超时导致迁移任务失败，扩容前最好先扫描一下有没有这种“问题Key”,想办法拆分它们或者特殊处理。
• 坑四：配置更新不同步，扩容完成后，集群的节点拓扑结构变了，虽然集群内部的节点彼此认识，但有些客户端（尤其是那些不是特别智能的）可能还是靠着最初的配置文件来连接集群，如果配置文件没及时更新加入新节点的信息，可能会导致客户端无法感知到所有节点，造成连接不均或部分失败,需要确保客户端的连接配置是动态的或者能自动发现集群节点。
• 坑五：忘了设置从节点，光加主节点不行，高可用不能丢，每加入一个新的主节点，最好紧接着就给它配上一个从节点（slave），做数据备份和故障转移，不然这个新节点万一挂了，它负责的那部分数据就不可用了，忙活半天扩容，结果可靠性还降低了,就得不偿失了。

Redis集群扩容是个精细活儿，不是点一下按钮就完事的，方案本身清晰，但真刀真枪操作时，对网络、客户端、数据特征都有要求，需要做好充分的预案、严格的监控和小心翼翼的节奏控制，每一次平稳的扩容背后,可能都藏着运维人员熬红的双眼。