43

【原创】你的Redis怎么持久化的 - 孤独烟 - 博客园

 4 years ago
source link: https://www.cnblogs.com/rjzheng/p/10990713.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

(本文改编自生活真实案例,如有类同,绝不是巧合!)
端午节,烟哥正在一边愉快的学习....
突然,微信一阵抖动。原来是老刘呼唤烟哥!善良的烟哥本以为人家是要约我出去玩!然而,打开微信一看,出现下图聊天记录
725429-20190608145504120-1926518440.jpg
于是本文的主题就这么展开了。由于我需要迅速让老刘明白,这种问题的回答套路,所以我回答的时候,教她的是一种通用做法。
ps:附《那些年用过的redis集群架构(含面试解析)》的连接地址。
当然,必须的,我一定要先问一下老刘答了哪种redis集群架构!老刘的回答是用了redis cluster集群架构。
于是,我一听心里就有底,开始balabala....

持久化套路

OK,一般我们在生产上采用的持久化策略为

  • (1)master关闭持久化
  • (2)slave开RDB即可,必要的时候AOF和RDB都开启

该策略能够适应绝大部分场景,绝大部分集群架构。
为什么是绝大部分场景?
因为这套策略存在部分的数据丢失可能性。redis的主从复制是异步的,master执行完客户端请求的命令后会立即返回结果给客户端,然后异步的方式把命令同步给slave。因此master可能还未来得及将命令传输给slave,就宕机了,此时slave变为master,数据就丢了。
幸运的是,绝大部分业务场景,都能容忍数据的部分丢失。假设,真的遇到缓存雪崩的情况,代码中也有熔断器来进行资源保护,不至于所有的请求都转发到数据库上,导致我们的服务崩溃!
ps:这里的缓存雪崩是指同一时间来了一堆请求,请求的key在redis中不存在,导致请求全部转发到数据库上。
为什么是绝大部分集群架构?
因为在集群中存在redis读写分离的情况,就不适合这套方案了。
幸运的是,由于采用redis读写分离架构,就必须要考虑主从同步的延迟性问题,徒增系统复杂度。目前业内采用redis读写分离架构的项目,真的太少了。

为什么这么做

(1)master关闭持久化

原因很简单,因为无论哪种持久化方式都会影响redis的性能,哪一种持久化都会造成CPU卡顿,影响对客户端请求的处理。为了保证读写最佳性能,将master的持久化关闭!
RDB持久化
RDB持久化是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化),保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。
那么RDB持久化的过程,相当于在执行bgsave命令。该命令执行过程如下图所示

725429-20190608145520717-1403252043.jpg

如图所示,主线程需要调用系统函数fork(),构建出一个子进程进行持久化!很不幸的是,在构建子进程的过程中,父进程就会阻塞,无法响应客户端的请求!
而且,在测试中发现,fork函数在虚拟机上较慢,真机上较快。考虑到现在都是部署在docker容器中,很少部署在真机上,为了性能,master不建议打开RDB持久化!
AOF持久化
RDB持久化是将进程数据写入文件,而AOF持久化(即Append Only File持久化),则是将Redis执行的每次写命令记录到单独的日志文件中。
随着时间的流逝,你会发现这个AOF文件越来越大,于是redis有一套rewrite机制,来缩小AOF文件的体积。然而,在rewrite的过程中也是需要父进程来fork出一个子进程进行rewrite操作。至于fork函数的影响,上面提到过了。
还有一个就是刷盘策略fsync,这个值推荐是配everysec,也就是Redis会默认每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。
然而,如果磁盘性能不稳定,fsync的调用时间超过1秒钟。此时主线程进行AOF的时候会对比上次fsync成功的时间;如果距上次不到2s,主线程直接返回;如果超过2s,则主线程阻塞直到fsync同步完成。
因此AOF也是会影响redis的性能的。
ps:linux函数中,wrtie函数将数据写入文件的时候,是将数据写入操作系统的缓冲区,还并未刷入磁盘。而fsync函数,可以强制让操作系统将缓冲区数据刷入磁盘。

综上所述,我们为了保证读写性能最大化,将master的持久化关闭。

(2)slave开RDB即可,必要的时候AOF和RDB都开启

首先,我先说明一下,我不推荐单开AOF的原因是,基于AOF的数据恢复太慢。
你要想,我们已经做了主从复制,数据已经实现备份,为什么slave还需要开持久化?
因为某一天可能因为某某工程,把机房的电线挖断了,就会导致master和slave机器同时关机。
那么这个时候,我们需要迅速恢复集群,而RDB文件文件小、恢复快,因此灾难恢复常用RDB文件。

其次,官网也不推荐单开AOF,地址如下:
https://redis.io/topics/persistence
截图如下
725429-20190608145602746-432986099.jpg

所以,如果实在对数据安全有一定要求,将AOF和RDB持久化都开启。

另外,做好灾难备份。利用linux的scp命令,定期将rdb文件拷贝到云服务器上。
ps:scp是secure copy的简写,用于在Linux下进行远程拷贝文件的命令,和它类似的命令有cp,不过cp只是在本机进行拷贝不能跨服务器,而且scp传输是加密的。

本文提出的是一种通用的持久化策略,主要目的是在面试的时候被问到,给出一个合理的回答,而不至于一脸懵逼。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK