本文转载自微信公众号《小菜两集》，作者蔡不才。转载本文请联系小菜良记公众号。大家好，我是小菜。一个希望成为吹牛皮谈建筑的男人！如果你想成为我想成为的人，或者跟我做伴，让小菜不再孤单！最近在面试的路上越走越远，Redis绝对是热门的面试方向。有多少种数据结构？如何实现延迟队列？淘汰机制是什么？问得都快麻木了，这些问题时常萦绕在脑中。那我们就来说说本文中一道比较常见，难度适中的面试题。Redis的持久化策略是什么？一开始就问一个问题。相信被问到Redis持久化的同学一定很多，答对的同学也一定很多。说起Redis的持久化，肯定有朋友会张嘴。毕竟有AOF和RDB这两个概念。只要你准备好面试，你就不会被问得太糟糕。但是你真的理解还是只是为了面试而背诵？你知道AOF和RDB的缩写是什么吗？实际的？4道题你答对了一半，还不如往下看，说不定你会有所收获，至少在回答面试题的时候心里有个小菜~！Redis持久化什么是Redis持久化？咱不记得往解题方向前进了，先搞明白这道题的意思。持久性意味着永久保存数据。那么什么是Redis持久化呢？也就是将Redis存储在内存中的数据写入磁盘，防止服务宕机时内存数据丢失。那么有朋友说，磁盘坏了，数据怎么持久化？就算多点备份可以解决磁盘损坏的问题，但是如果多点丢失了又如何恢复呢？打住，打住，我们这篇文章说的是Redis内存数据->磁盘持久化问题，别指望跟面试官聊半小时这个问题~！本文从几个方面来解释Redis的持久化问题。共有三个大方向和一个三步策略来解决您的持久性问题。1.RDB首先我们来解决其中一个开局问题。RDB的全称是什么？RDB(RedisDatabaseBackupfile)---Redis数据备份文件，也称为Redis数据快照。这个小工具是用来将内存中的所有数据记录到磁盘中的。当Redis实例出现故障重启时，从磁盘中读取快照文件来恢复数据。内心狂喜，看来第一个学到的概念就可以解决Redis的持久化问题了~在学习RDB之前，我们先了解一下fork和cow这两个核心概念。我们将在下面进行解释，这里有一个技巧。RDB是Redis默认的持久化机制。它将内存中的数据按照一定的时间段以快照的形式保存到磁盘中。它会生成一个特殊类型的file.rdb数据文件，你可以通过配置文件中的save参数来定义快照周期。我们从配置文件中的两个配置参数入手，第一个是保存配置。该指令由RDB的Redis主进程执行，会阻塞所有命令。我们在配置文件dbfilenamedump.rdb中找到了关于sava的配置。这个配置项的作用是定义rdb文件名（注意名字不能定义为路径只能定义为文件名）我们执行save命令后可以看到一个dump.rdb文件save在我们执行保存命令后在redis文件夹中。该配置项的作用是定义bgsave在多长时间内执行多少次，如果是save""，则表示禁用RDB。接下来我们打开测试的保存配置dbfilenamedump-test.rdb#文件名为dump-test.rdbsave36001#在?0秒内发生变化时，会执行bgsave。我们通过redis-cli进入运行，然后退出后，我们可以在当前目录看到刚才生成的dump-test.rdb文件，说明我们的配置生效了，然后我们直接重启Redis，看看我们的数据是不是刚刚保存的仍然存在。看到我们的数据，说明Redis持久化成功了。然后我们删除刚刚生成的dump-test.rdb文件，重启redis。这说明Redis在启动时依赖.rdb来恢复文件数据。那么上面我们一直在讲bgsave，bgsave是怎么执行的呢？我们之前提到过fork和cow这两个概念。不知道有没有印象。这两个概念是关键~！bgsave的开始有时候主进程会fork得到一个新的子进程，子进程共享主进程的内存数据。子进程会将数据写入磁盘上的临时.rdb文件。当子进程完成写入临时文件后，它将替换原来的.rdb文件。这就是fork的核心，那什么是cow呢？cow的全称是copy-on-write技术。当主进程执行读操作时，它访问共享内存，当主进程执行写操作时，它会复制一份数据。执行写操作。具体过程如下：这种持久化方式有什么优势？便于持久化。只有一个dump.rdb文件具有良好的容灾能力，可以将文件保存到安全磁盘以最大限度地提高性能。让主进程继续处理命令，最大化IO，保证Redis的高性能。缺点也有：数据安全性低，RDB是间隔持久化（保存）的。如果Redis在持久化时出现故障，会造成数据丢失，所以这种方式适合在对数据要求不是很严格的情况下使用。存放时间长。如果数据量很大，保存快照的时间会很长，而且会占用磁盘空间。AOFAOF的全称是AppendOnlyFile（追加文件）。作用是Redis处理的每条写命令都会记录在AOF文件中，可以看作是一个命令日志文件。该功能默认关闭。我们可以在redis.conf文件中查看AOF相关的配置项appendonlyyes#开启AOF日志记录功能，默认是关闭的appendfilename"appendonly.aof"#AOF文件的名称以上两个配置项是用到的启用AOF日志记录，所以还有一个额外的配置项，也需要知道appendfsynceverysec#AOF命令日志记录的频率。该配置项具有三个可选值。,几乎没有数据丢失,性能影响很大,everysecflashingpersecond性能适中,最多1秒数据丢失没有,操作系统控制性能最好,可靠性较差,可能丢失大量数据.了解Mysql中relaylog日志的同学，对这个模型一定不会陌生。原理：将写命令追加到AOF文件的末尾。使用AOF持久化，需要设置同步选项，保证写命令同步到磁盘文件。这是因为写入文件不会立即同步内存。相反，它首先存储在缓存中，然后由操作系统决定何时同步到磁盘。我们打开AOF记录功能查看一下：可以看到我们的每一个操作都被记录在了AOF文件中。我们也可以通过重启Redis获取到刚刚存储的数据，说明持久化生效了~大家看看是不是觉得上面的AOF记录文件很规律呢？但是在线上环境比较正规也不好，因为这个文件主要是给机器看的，不是给我们看的，所以我们应该可以压缩一下。为了解决AOF文件体积增大的问题，用户可以向Redis发送bgrewriteaof命令，Redis会通过去除AOF文件中的冗余命令来重写（rewrite）AOF文件，从而使AOF文件的体积变小尽可能。可能很小。bgrewriteaof的工作原理和bgsave创建快照很相似：Redis会创建一个子进程，然后子进程负责重写AOF文件。因为AOF文件改写也需要使用子进程，快照持久化中创建子进程带来的性能问题和内存占用问题在AOF持久化中同样存在。既然有手动触发压缩，也有自动触发压缩，也就是说配置文件auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb这两个配置项的意思是当AOF文件的体积为AOF文件大于64MB，且AOF文件的体积比上次重写后的体积至少大两倍（100%），Redis会执行bgrewriteaof命令。综上所述，其优点如下：数据安全。AOF持久化可以在appendfsync属性中配置always，每执行一次写命令操作，都会在AOF文件中记录一次，以保持一致性。通过append模型写入文件，即使中途服务器宕机，也可以使用redis-check-aof工具解决数据一致性问题。缺点是：AOF文件比RDB文件大，数据集大时恢复速度比RDB文件慢。低效率也等于优点和缺点。小心使用。三。两者的区别分别介绍两者。让我们回顾一下两者之间的区别。一方面，RDBAOF持久化方式会定时对整个内存进行快照，以记录每次执行的命令数据的完整性。备份之间会丢失不完整的相对完整性。根据刷机策略不同，文件大小会被压缩，文件小，记录命令，文件大，宕机恢复速度快，数据恢复优先级低，因为数据完整性没有AOF高，因为数据完整性更高。系统资源使用率高，大量CPU和低内存消耗，主要是磁盘IO资源。而且AOF改写会占用大量的CPU和内存资源。使用场景可以容忍数分钟的数据丢失。追求更快的启动速度对数据安全性提出了更高的要求。看完以上，想必对这两种持久化机制都有了一定的了解。我明白。两者各有优缺点，那么我们应该如何选择呢？这里有一些建议~如果你能忍受短时间的数据丢失，可以使用RDB机制，定时生成RDB快照，RDB恢复数据集的速度也一定要快于AOF恢复，但是如果单独使用RDB机制，可能会丢失很多数据，所以我们需要综合使用AOF和RDB两种持久化机制，使用AOF来保证数据不丢失，作为数据恢复的首选；使用RDB做不同程度的冷备份。在AOF文件丢失或损坏的情况下，可以使用RDB进行数据的快速恢复。我们可以使用RDB快速恢复数据，使用AOF补全数据。我们这里刚才讲了Redis持久化机制的配置。通过本文的学习，相信在面试中遇到这个问题时，我不会那么手足无措了~！不说空话，不偷懒，和小菜一起吹牛让X做架构的程序员~跟我做伴，让小菜不再孤单。下面见！
