提问
发动态
登录
没有新消息
更多内容
首页
问题
回答
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的访问压力有好转,但不是长久之计,比如遇到举办活动, 数据量增大时,还是会有性能的风险。
0
赞+1
0
评论
0
条评论
暂无评论,快来写下您的评论
问题来自于
咔啡
广东/湖南农业大学
Redis持久化数据和缓存怎么做扩容?
6553
阅读
3
回答
我要回答
邀请回答
推荐阅读
#贵州多彩博虹科技有限公司#这家公司的技术总监真次品、居然说redis不存在持久化、一副盛气凌人的样子……真不知到你之前是怎么工作的、应该是国企好混
2回答
8269阅读
Redis 的持久化机制是什么?各自的优缺点?
3回答
4389阅读
Redis的持久化有哪些方式?
0回答
1491阅读
Redis缓存应用场景
0回答
3082阅读
redis缓存的过期时间默认是半小时吗
1回答
5491阅读
什么是Redis持久化?
0回答
1386阅读
如何选择合适的持久化方式?
0回答
726阅读
高性能、高灵活性的 PHP 持久化框架 Hyperf
0回答
1306阅读
正在发声
热门搜索
🔥职QStar养成计划
职Q每日打卡
🔥做得一手好菜
职场相亲角
找工作找工作
披荆斩棘的老哥
乘风破浪的小姐姐
当代斜杠青年的自我修养
我的微笑☺
今天你做了哪些努力
锦鲤许愿池
一张图证明你的颜值
甜甜的恋爱
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的访问压力有好转,但不是长久之计,比如遇到举办活动, 数据量增大时,还是会有性能的风险。