推荐：《redis视频教程》
方案一：
首先想到的是，增加redis服务器的数量，在客户端对存储的key进行hash运算，存入不同的redis服务器中，读取时，也进行相同的hash运算，找到对应的redis服务器，可以解决问题，但是不好的地方：
第一，客户端要改动代码；
第二、需要客户端记住所有的redis服务器的地址；
这个方案可以使用，但能不能不用改动代码就能实现扩容呢？
方案二：
搭建一个集群，由于redis服务器使用的版本低于3.0，不支持集群，只能通过使用代理，就想到了有名的redis代理twemproxy。
twemproxy的性能也是杠杠滴，虽然是代理，但它对访问性能的影响非常小，连redis作者都推荐它。
twemproxy使用方便，对于一个新手来说，不到一个小时就能学会使用，而且关键是不用改动客户端代码，几乎支持所有的redis命令和管道操作，只需要改下客户端的配置文件中配置的redis的ip和port，由原来的redis的ip和port改成twemproxy服务的ip和port。
客户端不需要考虑hash的问题，这些twemproxy会做，客户端就像操作一台redis一样。
上面用了“几乎”这个词，因为有些命令，比如keys *就不支持
很快部署了好了twemproxy和后面跟着的四个redis机器，压测发现，后面的四台redis的cpu使用率降下来了，但新问题来了，twemproxy也是单进程的！性能瓶颈又跑到twemproxy上来了！
方案三：
对redis的访问分为写和读，类似生产者和消费者， 再仔细分析，发现写的少，读的相对多些，这就可以将读写分离，写的往主的写，读的从备的读，遇到的情况恰好是读和写是两个服务，做到读写分离通过改下配置信息就可以很简单的做到，，这样分散了主redis的压力。
这里对redis的访问压力有好转，但不是长久之计，比如遇到举办活动， 数据量增大时，还是会有性能的风险。
最终采用的方法是综合方案二和三，如下图所示：
这种方法对现有的服务改动最小，可以有效缓解redis压力的问题
producer端和consumer端的twemproxy使用的hash算法要求一致，不然找不到key了。
如果把方案一也加进来，会比较复杂，暂时用不到。
以上就是redis怎么扩容的详细内容。