当前位置:Gxlcms > redis > redis怎么扩容

redis怎么扩容

时间:2021-07-01 10:21:17 帮助过:67人阅读

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

推荐:《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怎么扩容的详细内容,更多请关注Gxl网其它相关文章!

人气教程排行