redis面试（四）持久化

什么是持久化？

由于redis是基于内存操作的轻量型数据库，所以如果发生宕机重启这种事情，存储的数据就会直接丢失，如果在里面存储了没有备份的数据，那么确实会对我们的业务造成一定影响。 所以我们要通过持久化的手段，将数据存入磁盘中，只要进入了磁盘，就不怕主机宕机重启。这部分数据除非主动删除，是可以一直存在，这就是持久化。

什么场景需要持久化？

一般情况下来说，我们使用redis只是给数据库加一层防护，防止大量的流量直接打到数据库导致数据库宕机，进而引发系统整体瘫痪。
在真正的业务处理中，大量访问的数据其实都是一些热点数据，那么这些热点数据我们做一层缓存，就可以拦截大量的流量，不需要将请求再发送给数据库。 减少了与数据库的链接，也就是减少了大量的IO耗时。 那么也就做到了单次请求的耗时减少，自然而然的 QPS就能整体提升。
扯得远了，说回到redis，在上面的单纯做数据缓存的场景，其实是没有必要进行数据持久化。 因为就算系统宕机重启，查询不到数据的时候，无非是去数据库里面再捞一把，重新存入缓存中就可以了，这部分数据是天然就在数据库里面持久化过的。

那说了这么多，到底什么场景才需要？ 我给的答案是，除非是真的将redis当成所有业务数据的最终存储位置，所有的业务流转都是基于redis来操作，没有其他任何天然持久化的数据库如：mysql、es等等。 这个时候才是一定需要持久化的。
只要是数据可以通过其他手段重新更新到redis中的话，就没有必要在redis进行持久化操作。

哦，有的朋友可能会说，那总有些业务数据是先更新到缓存中，然后再更新到数据库中的吧，如果这个时间差里面，数据丢失了怎么办？ 对于这种，redis是可以做分布式多节点备份，主节点宕机了，副节点一样会有一份备用数据。

又有朋友说了，那如果所有节点都宕机了，怎么办？ 这种场景，我们要想一下，到底是丢失了多久的数据？ 从数据进入缓存，到数据异步落库，这个时间差真的会很久吗？如果这个过程中要保证数据100%不丢失的话，redis可以做到，但是！ 这个过程的产生的耗时，与直接进入数据库还有区别吗？ 我们使用redis不就是为了提升性能对吧。

可能还有朋友说了，那如果真的是比较重要的数据，又对性能要求比较高，比如最常见的秒杀系统，可以是基于reids来处理的，如果这个过程中数据丢失了，那不就会造成秒杀系统出问题么。 对于这种，我只想说，如果在推广秒杀的这么重要的时刻，还能发生redis宕机的问题，最好是转行吧，别做商家系统了，会赔死的。
（这些问题确实是在面试中遇到过）

言归正传，但是redis既然有这个持久化的功能，那一定就是有人会问的，我们就来剖析一下

持久化策略

持久化的策略简单来说分为两种，AOF 和 RDB
AOF是一种热备份，就是在我们不断的更新数据的时候，他会不断的将我们更新的数据持久化到磁盘中，这个基本上时间差就是ms级别的。 缺点就是可能会对我们更新reids产生一定性能上的影响。
RDB是一种定时冷备份，就是每隔一段时间，将数据整体备份一次，备份的间隔期间是不会对我们的请求造成影响。缺点就是在备份的过程中可能会影响我们的更新操作，并且会丢失一定时间内的数据。

RDB

全称是Redis Database Backup file，直译是redis数据备份，我们称之为数据快照。

自动备份：
在配置文件中配置，需要注意的是，这种快照备份，是会阻塞redis服务器，不能处理其他命令，直到备份完成

# 900秒内至少1个键被修改则进行快照
save 900 1# 300秒内至少10个键被修改则进行快照
save 300 10# 60秒内至少10000个键被修改则进行快照
save 60 10000

手动备份：
执行命令，bgsave 这个命令是手动开启一个子进程，过程中不会阻塞其他的reids命令

RDB备份的流程
备份数据的时有一个fork(创建)一个子进程的动作，将主进程中的所有内容全部复制，然后进行一个数据复制备份的操作，这个fork是什耗费时间的。 所以如果性能要求比较高的话，建议可以关闭默认的save，在服务器上用shell写一个定时器，每天的固定时间去执行bgsave命令，可以提高系统的性能。缺点就是可能会丢失一定的数据。

AOF

全称是Append Only File ，是一个命令追加保存的策略。
将每个命令都存储到aof文件中，恢复数据的时候是进行命令回放来。

AOF的配置参数：

• appendonly：是否开启AOF持久化策略，默认为no。
• appendfilename：AOF文件的名字，默认为"appendonly.aof"。
• appendfsync：AOF文件的同步模式，有always、everysec、no三种模式。
• no-appendfsync-on-rewrite：在AOF重写时，是否停止同步，默认为no。
• auto-aof-rewrite-percentage：AOF文件长度增长的百分比，超过该百分比进行AOF文件重写。默认100
• auto-aof-rewrite-min-size：AOF文件重写触发的最小文件体积。默认64mb

同时开启aof和rdb策略的话，优先使用aof

备份流程：

• 客户端发送写操作命令给Redis服务器。
• 服务器接收到命令，将其写入内存中，并将该命令添加到AOF缓冲区。
• AOF缓冲区根据策略可能会被同步到硬盘上的AOF文件中。
• Redis服务器定期检查AOF文件的大小，并进行AOF重写操作，即压缩AOF文件。
• 如果Redis服务器异常，会从AOF文件中读取命令进行数据恢复。

AOF重写操作 aof rewrite
设置了auto-aof-rewrite-percentage或者auto-aof-rewrite-min-size会触发重写操作。
size配置很清晰，意思是超过多大就要重写。
percentage的意思是，本次的文件大小，和上次的文件大小对比，超过百分之多少就进行重写。

为什么要重写aof文件
因为命令是不断接收的，所以文件肯定也是不断的增大，如果过大的话一定会对cpu造成负担，IO性能下降，内存消耗过大。所以就要进行文件瘦身操，将命令梳理一遍。 比如已经del的数据，那所相关的命令肯定就没有存在的必要了。

重写的时候也是fork出来一个子进程，然后扫描当前reids所有的键值对，生成一份新的aof文件。
这个过程中redis是没有阻塞，还在不断的接收新的命令，这些新的命令会存在aof缓冲区，等到新的aof完成的话，再将这些新命令存入新的aof文件中

总结

最优的持久化手段就是，AOF和RDB配合使用，因为AOF文件命令恢复数据是比较慢的。

• 定时的通过shell来进行定时的rdb快照备份。
• 然后再通过aof文件来进行缺失数据的补充。