Redis扩容技巧大公开，架构师亲授，你是想学基础操作还是高级策略？

扩容Redis时，基础操作是垂直扩容，也就是给服务器加内存CPU，简单直接但有限制；高级策略是水平扩容，用集群分片来应对大数据量高并发，这才是长久之计。

一、基础操作：垂直扩容，快速见效

垂直扩容说白了就是升级硬件。比如你的Redis跑在4核8G的机器上，发现内存快满了，性能开始下降，那就换个8核16G或者更大的机器。操作起来挺简单：先在新的服务器上安装好Redis，把配置文件调好；然后暂停旧Redis的服务（或者用主从复制尽量减少停机时间），把旧的数据文件（RDB或AOF文件）拷贝到新机器；接着在新机器启动Redis，让它加载数据；最后把应用程序连接的Redis地址改成新机器的IP和端口。这个办法适合数据量不是特别大、而且业务能接受短暂停机的场景。但要注意，硬件不可能无限升级，而且单机风险高，万一这台机器出问题，整个服务就挂了。

二、高级策略：水平扩容，分布式解决

水平扩容才是解决大数据问题的关键。核心思想是把一个大的Redis拆成多个小的实例，每个实例只存一部分数据，然后通过集群管理起来。Redis Cluster是官方方案，它自动把数据分到16384个槽里，每个节点负责一部分槽。客户端请求时，如果数据不在当前节点，节点会告诉客户端正确的节点地址，让客户端重定向。搭建集群的步骤大概是：准备好几台服务器，每台上跑一个或多个Redis实例作为节点；然后用redis-cli工具或者配置文件，把这些节点组成集群，并分配好槽。这样扩容的时候，可以动态增加节点，然后把一部分槽和数据迁移过去。另一种常见做法是用Twemproxy或者Codis这样的代理中间件，由代理来负责分片和路由，对客户端来说就像访问一个Redis一样，后台实际是多个实例。水平扩容的好处是容量和性能都能线性增长，而且可靠性更高，但管理起来复杂一些，需要监控每个节点的状态。

三、实战经验：平滑迁移不停服

不管是垂直还是水平扩容，最好能做到业务不停机。这里有个常用技巧：利用Redis的主从复制。比如你要把数据迁移到新集群，可以先在新集群的某个节点上设置它为旧Redis的从节点，让数据同步过来；等数据同步完成，把这个从节点提升为主节点，然后逐步把应用的连接切换到新集群。对于水平扩容，Redis Cluster支持重新分片，可以在线把一些槽从旧节点迁移到新节点，迁移过程中这些槽的数据还是可读写的。关键是要慢慢切流量，比如先切10%的请求到新集群，观察没问题再全量切换。监控指标很重要，要看内存使用、响应延迟、错误率，确保迁移平稳。

四、常见问题FAQ

1. Redis扩容时数据如何保证不丢失？
尽量用主从复制做数据同步，在业务低峰期操作，并确保开启了持久化（AOF或RDB）。迁移前后做数据一致性检查。

2. 水平扩容后，客户端要怎么连？
如果用的是Redis Cluster，客户端需要支持集群协议，比如Java的JedisCluster，它会自动处理节点重定向。如果用代理像Codis，客户端连代理地址就行。

3. 扩容后性能反而下降了怎么办？
可能是数据分片不均匀导致热点，或者集群网络延迟高。检查数据分布，避免大key；网络上尽量让同机房的节点组成集群。

五、参考资料

1. Redis官方文档关于复制的部分：https://redis.io/docs/management/replication/
2. Redis Cluster官方说明：https://redis.io/docs/management/scaling/
3. 一些开源代理工具如Codis的GitHub页面：https://github.com/CodisLabs/codis