Redis 后端之 Redis 持久化
Redis 是出了名的速度快，那是因为在内存中进行数据存储和操作；如果仅仅是在内存中进行数据存储，那就会导致以下问题：
数据随进程退出而消失：当服务器断电或 Redis Server 进程退出时，内存肯定随之释放，最后数据也会丢失；可能有些小伙伴认为只是作为缓存，数据没有了，重新从数据库中读取放在里面即可，试想，如果是高并发场景，数据库岂不是压力很大；
重要数据无法恢复：数据丢失之后无法进行恢复，对于一些重要的数据，只是存在 Redis 中，而没有存在关系型数据库，如果数据丢失便不可恢复；比如刷礼品排行榜，如果数据丢失，用户肯定不愿意的；
对于 Redis 持久化在工作中和面试过程中是一个很重要的技术点，必用必考，接下来详细说说 Redis 持久化；
Linux 后端开发 redis 相关视频：Redis 详解 rehash、布隆过滤器、redis 持久化：https://www.bilibili.com/video/BV1a64y1D74v redis 源码学习：https://www.bilibili.com/video/BV1c
正文
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 的值修改了就进行持久化到磁盘，如下：
先将原有的 dump.rdb 文件删除掉，避免影响测试效果；
修改配置文件如下：
用修改之后，指定该配置文件重启 redis-server，然后开始测试；
尝试打开 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 备份流程
简要说明：
当触发 bgsave 持久化时(满足配置条件或手动执行 bgsave 命令)，主进程 fork 一个子进程进行持久化操作，主进程不参与任何持久化 IO 操作；
为了不影响原有 rdb 文件的使用，子进程会将快照数据先写入到临时文件;
当快照数据完全备份到临时文件时，就替换掉原有的 rdb 文件，从而得到最新数据的 rdb 文件；
注：当执行 sava 命令的时候，会导致阻塞，只有等快照数据持久化完成之后，才能做其他事情；
RDB 持久化优缺点
每一项技术在解决已有问题的时候，肯定也会带来新问题，RDB 用来解决持久化问题，那它有什么优缺点呢？
优点
RDB 保存的数据文件比较紧凑，对比 AOF 来说，相同数据的文件大小比较小；
大量数据持久化时速度相对 AOF 比较快；
RDB 中 bgsave 模式对主进程影响比较小，只有在主进程 fork 子进程的时候耗费资源，但影响不大；自动备份后台用的就是 bgsave 模式；
缺点
RDB 可能会丢失最后一次没有备份的数据，如果在最后一次没开始备份之前，服务器挂了，那最后一次的数据就没了；
当数据量巨大时，主进程在 fork 子进程的时候，可能会导致稍微的卡顿；
AOF 持久化
既然已经有了 RDB 持久化了，那为什么还得出一个 AOF 呢？从 RDB 的缺点来看，很大程度上是因为可能会丢失最后一次备份之前的数据，对于一些重要数据来说，是不能接受的。而 AOF 的出现，将数据丢失风险极大的降低。先不说那么多，实操一把再慢慢聊。
AOF 默认情况是没开启的，打开配置文件，为了不让 RDB 备份影响，这里暂时先将 RDB 备份禁用掉，如下：
禁用 RDB 备份：
开启 AOF 备份：根据上一篇文章提到的，先找到 APPEND ONLY MODE 配置块，将 AOF 备份开启appendonly yes
配置好了，指定配置文件重启 redis-server，先来看看效果：
当一启动 redis-server 的时候，appendonly.aof 文件就已经生成了；来，咱们接着敲点命令，如下↓↓↓
尝试打开 appendonly.aof 文件看看，和 dump.rdp 文件有什么不同；
appendonly.aof 只记录写命令，读命令不记录，而且记录方式是以追加的方式，所以速度相对比较快；
同 RDB 一样，在 redis-server 重启时，自动加载 AOF 文件命令依次执行，最终将数据进行恢复；
AOF 其他配置项
这就是 Redis 的强大，针对每一个功能都可以通过配置项进行完成，使用非常方便；
appendonly：默认 no，不开启 AOF 持久化；可以通过设置为 yes 开启；
appendfilename：默认 appendonly.aof，代表生成的 AOF 日志文件名，可以更改；
appendfsync：默认 everysec，设置同步命令到磁盘的策略，即默认每秒通过 fsync 进行一次命令同步到磁盘；有三种命令同步策略可以选择，如下：
always：只要有写入命令就通过 fsync 同步到磁盘，数据完整性好，但效率不好；
everysec：每秒通过 fsync 进行一次命令同步到磁盘，可能会导致一秒中数据的丢失，因为可能在命令还没同步的时候，机器挂掉等操作，但可接受；综合考虑，推荐使用这种策略；
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 重写流程
简要说明：
当触发到重写 AOF 文件时，主进程 fork 一个子进程，子进程根据内存中的现有数据进行命令精简化，重写到新的 AOF 文件中；
在子进程正在重写 AOF 文件时，如果有新的写命令，将其存放到重写缓冲区，同时也同步到原来的 AOF 文件；
当子进程重写完成之后，通知主进程将重写缓冲区中的新命令写入到新 AOF 文件中，完成之后，用新的 AOF 文件将原来的 AOF 文件替换；
最后得到优化之后的 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 文件相对比较完整；
LinuxC/C++服务器开发/架构师面试题、学习资料、教学视频和学习路线脑图（资料包括 C/C++，Linux，golang 技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），免费分享有需要的可以自行添加学习交流 群960994558
总结
暂时就到这吧，后续遇到相关问题再来记录分享；这个知识点比较重要，所以小伙伴们一定要自己尝试一下哦；使用真的很简单，进行简单的配置就完事了，如果能知道其简单的原理，遇到问题就没那么苦恼；
C/C++Linux服务器开发学习群960994558 2020.11.28 加入
纸上得来终觉浅，绝知此事要躬行
评论