设为首页 收藏本站
查看: 801|回复: 0

[经验分享] Redis持久化之大数据服务暂停问题

[复制链接]

尚未签到

发表于 2018-11-6 11:20:05 | 显示全部楼层 |阅读模式
  Redis持久化是有两种方式:RDB和AOF
  对这两种方式的官方文档的翻译请看:
  http://latteye.com/2011/11/redis-persistence.html
  RDB就是快照存储,比如“每1个小时对redis进行快照存储”。那么,
save这个参数就应该设置save 3600 1000   //前一次快照3600秒后,当有超过1000个key被改动的时候就进行一次快照更新RDB快照产生dump.rdb文件,当每到快照时间,更新文件。AOF是存储所有的写操作,分两个步骤:fsync和rewritefsync是把内存中的写操作写入aof文件中rewrite是将写操作合并,比如set aa 1; set aa 2; 两个操作应该写成一个操作set aa 2;如果数据量小的话,啥问题也没有现在假设服务器是20G内存,而且服务器上仅仅只有跑redis一个占内存的进程,就是说redis最多可以跑20G物理内存现在压入13G的redis数据(可以使用phpredis循环压入,但是要注意设置php的运行内存大小,最好使用pipeline的方式,否则php出现内存不足的error)尝试1,我们只使用RDB的方式当进行快照的时候(测试时候可以把快照间隔时间定成30秒或更短)top查看进程  26376 test 16 0 13.5g 13g 7488 D 0.0 42.8 6:48.24 redis-server
  32459 test 18 0 13.5g 13g 7200 D 1.3 42.8 0:23.22 redis-server
看到有两个进程,同时在运行,并且占用同样大小的内存数,和起来竟然占用26G之大~!现在redis服务端上两个进程都运行,看看客户端:测试redis-cli set操作:  redis 10.1.0.108:6379> set test2 22
  耗时(40.47s)近1分钟
  就是说在大数据量的时候,做RDB,redis服务会暂停近1分钟!这个就是redis持久化的时候的服务暂停现象。
  好吧,为了保证数据容错性,我们的快照一般是要频繁快照的,所以暂停一分钟是不可容忍的。
  现在尝试使用AOF+RDB
  1 将RDB的快照时间设置为1天(由于加上了AOF,所以这个时间是合理的)。
  2 1次性压入1000w左右的string数据到redis中(大概有5G数据量)
  3 查看性能表现:
  第一个步骤fsync:
  redis会从内存中逐渐生成appendonly.aof  在这个过程我试了下set和get操作都是没有暂停现象的(很好~!)
  好了,现在appendonly.aof生成了,有5.7个G
  -rw-r--r-- 1 root root 4186238374 Mar 6 15:50 appendonly.aof
  第二个步骤:调用BGREWRITEAOF重写aof文件
  这个时候top查看:
  看到也是两个redis-server服务开着。说明rewrite的时候是fork一个子进程在rewrite的,主进程是进行着redis服务的。
  这个时候redis-cli调用检查
  get操作:无延时
  set操作:出现了延迟现象 !!
这个说明AOF在重写的时候会占用服务器的大量CPU和内存资源,导致服务出现短暂暂停现象!但是为什么get操作没有出现延迟现象呢?参考官网文章,看到一个配置项:no-appendfsync-on-rewrite  这个配置项是设置在rewrite的时候是否对新的写操作进行fsync。no表示进行fsync,yes表示不进行
  默认是设置为no
  现在将这个配置项设置为yes(我们对于rewrite的aof文件硬盘大小没有很大要求)
  重新进行测试:
  对同样的5.7G的AOF操作进行一次BGREWRITEAOF。
  get操作:无延迟
  set操作:无延迟
  很好!说明在rewrite的时候如果不进行fsync操作,主进程和子进程是互不干扰的。
  那么如果rewrite的时候对新的写操作不进行fsync,那么新的aof文件里面是否会丢失这个写操作呢?
  答案是不会的,redis会将新的写操作放在内存中,等待rewrite操作完成的时候,将新操作直接挂在aof中。
  好了,至此,这个问题应该已经可以过去了。
  推荐几个文章:
  对数据持久化的一些想法:http://www.yiihsia.com/2011/04/%E5%AF%B9redis%E6%95%B0%E6%8D%AE%E6%8C%81%E4%B9%85%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%83%B3%E6%B3%95/
  (这个文章提供了一个非常好的方法,当数据量大,内存足够的情况,一台机子上尽量多开几个redis,甚至可以考虑有几个cpu就开几个redis,这样,每个redis的内存量不会太大,就不会有大数据量服务暂停问题,这个也是考虑到了redis是单线程的,能尽量利用CPU)
  redis的内存陷阱:http://www.iteye.com/topic/808293
  (这个文章很好解释了问什么大数据量的时候会出现服务暂停)
  Copy on write does not seem to work.: http://code.google.com/p/redis/issues/detail?id=150



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-631493-1-1.html 上篇帖子: redis主从+sentinel 下篇帖子: Redis高可用方案(redis主从+keepalived+sentinel)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表