Redis简单扩容经验谈

最新推荐文章于 2025-10-16 10:58:23 发布

原创

最新推荐文章于 2025-10-16 10:58:23 发布 · 1.2w 阅读

17 ·

CC 4.0 BY-SA版权

随着访问量增加，Redis的CPU使用率达到90%+，成为性能瓶颈。为解决此问题，尝试了多种方案：使用twemproxy进行代理，实现无代码改动的扩容，但twemproxy也成为新的瓶颈。最后采取读写分离结合多个Redis实例，有效缓解压力。关键在于理解业务场景，选择合适的技术方案。

team中的一个同学在其项目中使用了Redis作为缓存，将热点数据存放在Redis中。为了提升性能，写Redis时采用了管道的方式，平时使用时，Redis的性能、资源使用都能符合项目需求，但当访问量增加的时候，Redis的QPS还能满足要求，但CPU使用率高的时候已经达到90%+，平时只有30%+，而众所周知，Redis是单进程的，只能占用1个CPU核，跑满了也就100%，无法利用机器的多核，而当CPU跑到100%时，必然会造成性能瓶颈。怎么解决？

方案一：

首先想到的是，增加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和后面跟