跟我一块儿学Redis之Redis持久化必知必会

前言

Redis是出了名的速度快，那是由于在内存中进行数据存储和操做；若是仅仅是在内存中进行数据存储，那就会致使如下问题：

• 数据随进程退出而消失：当服务器断电或Redis Server进程退出时，内存确定随之释放，最后数据也会丢失；可能有些小伙伴认为只是做为缓存，数据没有了，从新从数据库中读取放在里面便可，试想，若是是高并发场景，数据库岂不是压力很大；
• 重要数据没法恢复：数据丢失以后没法进行恢复，对于一些重要的数据，只是存在Redis中，而没有存在关系型数据库，若是数据丢失便不可恢复；好比刷礼品排行榜，若是数据丢失，用户确定不肯意的；

对于Redis持久化在工做中和面试过程当中是一个很重要的技术点，必用必考，接下来详细说说Redis持久化；

正文

Redis针对数据持久化有两种方案，以下：

• RDB(Redis DataBase)：快照形式，即指定时间间隔将Redis内存中的快照数据保存在物理磁盘上，数据保存在*.rdb文件中，以二进制的形式进行存储，恢复数据直接加载便可；
• AOF(Append Only File)：日志形式，即将每条写命令以append-only模式记录在*.aof文件中，不能修改文件，只能进行追加；后续恢复数据自动执行日志文件中的命令便可恢复数据；
• 混合就是RDB和AOF的结合；

两种方式均可以经过配置文件轻松搞定，来，我们先从RDB开始；

fork：后续会频繁提到，简单解释一下，fork的做用是复制一个与当前进程同样的子进程，该子进程的全部数据都和原进程一致。

RDB持久化

理论放到后面再说，先来看看实际操做，再来作总结；上次对配置文件简单进行说明，此次就直接找到快照那配置就行啦，先看看默认配置：

经过 save <seconds> <changes>进行条件配置，若是触发条件就自动进行RDB持久化操做。默认配置中包含如下三种条件，知足其中一个就自动保存数据到磁盘：

• save 900 1：900秒内(15分钟)至少有1个key的值进行修改；
• save 300 10：300秒内(五分钟)至少有10个key的值进行修改；
• save 60 10000：900秒内(1分钟)至少有10000个key的值进行修改；

测试验证

为了测试时间方便，将其中一个条件改成1分钟内有3个key的值修改了就进行持久化到磁盘，以下：

1. 先将原有的dump.rdb文件删除掉，避免影响测试效果；

2. 修改配置文件以下：

3. 用修改以后，指定该配置文件重启redis-server，而后开始测试；

4. 尝试打开dump.rdb看看，咋一看是看不懂，但实际上是有对应关系的，这里就不深究了

Redis强大吧，不知不觉的就把数据备份，主要是还不影响正常操做，上图中第四步中就有体现，主进程fork了子进程进行备份，主进程不参与备份持久化操做。既然备份文件有了，如何进行恢复数据呢？ redis-server在启动的时候自动将当前目录中的备份文件(dump.rdb)数据加载到内存中；以下图所示：

RDB其余配置项

那为何是dump.rdb文件？，为何又是当前目录？，若是rdb备份文件写入失败了怎么办？这些经过配置文件中SNAPSHOTTING部分都有详细的说明，并提供相关配置项进行设置，以下：

• stop-writes-on-bgsave-error：默认设置为yes，即当RDB备份数据失败时，Redis会中止接收数据，保证数据的一致性；若是对数据一致性要求不高的，能够将其进行关闭，设置为no，但推荐都开启；
• rdbcompression：默认设置为yes，开启压缩以后会采用LZF算法对备份文件dump.rdb进行压缩，但会消耗点CPU性能进行处理，但影响并不大，推荐都开启；
• rdbchecksum：默认设置为yes，即开启以后会对备份文件数据进行校验，但会消耗CPU性能，若是追求性能提升能够将其关闭，但影响也不大，推荐都开启；
• dbfilename：默认为dump.rdb，即默认的备份文件名为dump.rdb，能够经过这个配置进行修改；
• dir：默认为当前目录，即备份的文件存放的目录。

RDB手动触发备份

上面说到自动触发备份，其实在实际应用场景中，有些需求很急，若是要求等到知足条件备份完成以后才处理问题，间隔时间短还好点，若是间隔时间超过5分钟，估计等待处理问题的人要上房揭瓦啦；Redis一样为你们考虑到了，提供手动备份的方式，以下：

• save：直接执行save命令，但会阻塞主进程操做，只能等待备份完成以后才能进行其余处理；
• bgsave：直接执行bgsave命令，主进程会fork一个子进程进行备份操做，不阻塞主进程；当数据过大时，可能会在fork的时候有短暂的耗时，但影响不大； 上面的自动备份其实最后也是bgsave这种模式。
• flushall：执行flushall命令会触发RBD备份，可是备份文件是空的，在本地测试一把就好了，没有任何意义，千万别在生产库上用；

简单测试一下，删除dump.rdb文件，将配置文件恢复到默认值，而后指定配置文件重启redis-server，以下：

如何中止或禁用RDB快照自动备份

能够经过配置文件的形式配置，也能够经过命令的形式进行关闭，但经过命令的方式，服务器重启以后就失效了，因此通常建议经过配置文件进行配置；

• 配置文件方式：去除全部关于save的配置，或者配置一个save ""便可，重启redis-server；
• 命令方式：在客户端中执行config set save ""便可，但redis-server重启时就恢复默认值了；

RDB备份流程

简要说明：

1. 当触发bgsave持久化时(知足配置条件或手动执行bgsave命令)，主进程fork一个子进程进行持久化操做，主进程不参与任何持久化IO操做；

2. 为了避免影响原有rdb文件的使用，子进程会将快照数据先写入到临时文件;

3. 当快照数据彻底备份到临时文件时，就替换掉原有的rdb文件，从而获得最新数据的rdb文件；

   注：当执行sava命令的时候，会致使阻塞，只有等快照数据持久化完成以后，才能作其余事情；

RDB持久化优缺点

每一项技术在解决已有问题的时候，确定也会带来新问题，RDB用来解决持久化问题，那它有什么优缺点呢？

优势

• RDB保存的数据文件比较紧凑，对比AOF来讲，相同数据的文件大小比较小；

• 大量数据持久化时速度相对AOF比较快；

• RDB中bgsave模式对主进程影响比较小，只有在主进程fork子进程的时候耗费资源，但影响不大；自动备份后台用的就是bgsave模式；

缺点

• RDB可能会丢失最后一次没有备份的数据，若是在最后一次没开始备份以前，服务器挂了，那最后一次的数据就没了；
• 当数据量巨大时，主进程在fork子进程的时候，可能会致使稍微的卡顿；

AOF持久化

既然已经有了RDB持久化了，那为何还得出一个AOF呢？从RDB的缺点来看，很大程度上是由于可能会丢失最后一次备份以前的数据，对于一些重要数据来讲，是不能接受的。而AOF的出现，将数据丢失风险极大的下降。先不说那么多，实操一把再慢慢聊。

AOF默认状况是没开启的，打开配置文件，为了避免让RDB备份影响，这里暂时先将RDB备份禁用掉，以下：

1. 禁用RDB备份：

2. 开启AOF备份：根据上一篇文章提到的，先找到APPEND ONLY MODE配置块，将AOF备份开启appendonly yes

3. 配置好了，指定配置文件重启redis-server，先来看看效果：

   当一启动redis-server的时候，appendonly.aof文件就已经生成了；来，我们接着敲点命令，以下↓↓↓

4. 尝试打开appendonly.aof文件看看，和dump.rdp文件有什么不一样；

   
   appendonly.aof只记录写命令，读命令不记录，并且记录方式是以追加的方式，因此速度相对比较快；

同RDB同样，在redis-server重启时，自动加载AOF文件命令依次执行，最终将数据进行恢复；

AOF其余配置项

这就是Redis的强大，针对每个功能均可以经过配置项进行完成，使用很是方便；

• appendonly：默认no，不开启AOF持久化；能够经过设置为yes开启；
• appendfilename：默认appendonly.aof，表明生成的AOF日志文件名，能够更改；
• appendfsync：默认everysec，设置同步命令到磁盘的策略，即默认每秒经过fsync进行一次命令同步到磁盘；有三种命令同步策略能够选择，以下：
  1. always：只要有写入命令就经过fsync同步到磁盘，数据完整性好，但效率很差；
  2. everysec：每秒经过fsync进行一次命令同步到磁盘，可能会致使一秒中数据的丢失，由于可能在命令还没同步的时候，机器挂掉等操做，但可接受；综合考虑，推荐使用这种策略；
  3. no：不一样步，由操做系统处理，这种数据不能保证安全；
• auto-aof-rewrite-percentage：默认100，搭配auto-aof-rewrite-min-size一块儿触发AOF文件重写策略，即默认当当前AOF文件大小是上次重写的两倍时才重写，为了不比率达到触发条件，但文件很小就触发重写的状况，因此搭配auto-aof-rewrite-min-size设置AOF文件的最小重写大小；即当前AOF文件大小达到比率的同时文件大小不低于auto-aof-rewrite-min-size设置的值才触发重写；
• auto-aof-rewrite-min-size：默认64mb，搭配auto-aof-rewrite-percentage使用；

AOF触发重写

当执行的写命令过多时，就会致使AOF文件过分增大，而对于一些重复性的命令存在AOF文件中是没有必要的，以下图所示：

上图中屡次对a1这个Key进行屡次写入，最终的值为10，可见若是AOF文件中只记录一条最终值的写命令岂不是最好，从而减小AOF文件的大小；这里文件大小确定达不到自动触发重写的条件，这里就手动触发，而后再看看AOF文件内容，是否进行了优化，以下：

如上图可见，重写以后的AOF文件的确是咱们本身想要，是否是以为Redis更加牛X了；触发重写有如下两种方式：

• 自动触发：即当知足设置的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size值会自动触发重写；
• 手动触发：在客户端中执行bgrewriteaof命令；

AOF重写流程

简要说明：

1. 当触发到重写AOF文件时，主进程fork一个子进程，子进程根据内存中的现有数据进行命令精简化，重写到新的AOF文件中；
2. 在子进程正在重写AOF文件时，若是有新的写命令，将其存放到重写缓冲区，同时也同步到原来的AOF文件；
3. 当子进程重写完成以后，通知主进程将重写缓冲区中的新命令写入到新AOF文件中，完成以后，用新的AOF文件将原来的AOF文件替换；
4. 最后获得优化以后的AOF文件，减小文件大小；

AOF文件修复

对于AOF文件内容的合法性怎么解决呢，有可能因为忽然事件，好比宕机，致使AOF文件写入不完整；也有可能有人恶意添加不规范数据，redis会怎么处理呢？这里就模拟手动修改AOF文件，以下：

根据提示，使用redis-check-aof --fix <filename>进行修复，以下：

启动图就不截了，小伙伴们试试去；还有redis也能对rdb文件修复，文中没有体现，但小伙伴记得去尝试一下，用redis-check-rdb这个工具便可，在windows版本中redis没有提供此工具，去linux用高点的版本实操一把。

AOF持久化优缺点

AOF的出现，是解决了RDB丢失最后一次没保存的数据，极大的下降了数据丢失的风险，但其也带来相关问题；

优势

• 下降数据丢失风险，若是丢失，最多一秒数据；
• 以追加方式记录日志，速度快；
• 自动优化AOF文件，文件过大时进行重写，精简AOF文件；

缺点

• 相同大数据，AOF文件比RDB文件大，占用磁盘空间；
• 对于大数据的恢复，速度没有RDB快；

混合持久化

在redis4.0以后，提供了混合持久化配置开启功能； 混合持久化就是结合RDB和AOF各自优势进行整合的持久化方案，从而解决使用AOF恢复数据较慢的问题；

原理就是在AOF文件的前半段加入RDB快照数据，后面才是增量数据的命令记录；在配置文件中进行配置便可：aof-use-rdb-preamble yes，高版本redis都默认开启这种混合持久化模式；

优势：解决了单纯AOF恢复数据较慢的问题；

缺点：不能兼容低版本redis场景；

选择哪一个持久化比较合适？

若是需求对数据完整性要求不是很高，能够接受短期数据丢失，RDB快照持久化方式是最好不过的选择；

若是对数据完整性要求比较严格，使用AOF日志形式进行持久化比较合适；

若是redis版本在4.0以上，可使用混合持久化的方式，下降纯AOF文件的恢复数据的时间；

若是仅仅是缓存，缓存数据也不重要，并发也不是很高，能够不用开启持久化；

注： 若是不是使用混合持久化，而是将RDB和AOF同时开启，redis-server恢复数据的时候会优先使用AOF文件进行数据恢复，由于AOF文件相对比较完整；

总结

暂时就到这吧，后续遇到相关问题再来记录分享；这个知识点比较重要，因此小伙伴们必定要本身尝试一下哦；使用真的很简单，进行简单的配置就完事了，若是能知道其简单的原理，遇到问题就没那么苦恼；下次咱们来聊redis的主从复制；

一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一块儿学~~~