浅谈Redis的持久化------RDB和AOF

Redis的常用功能
Redis的强大功能很大程度上是由于其将所有数据都存储在内存中，也就是做缓存，缓存的目标主要是那些需要经常访问的数据，或计算复杂而耗时的数据。缓存的效果就是减少了数据库读的次数，减少了复杂数据的计算次数，从而提高了服务器的性能。

1.redis持久化的两种方式

为了使Redis在重启后仍能保证数据不丢失，需要将数据从内存中以某种形式持久化到硬盘中。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将两种结合使用。RDB是Redis的默认持久化方式。

• RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
• AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

2.redis持久化之RDB

RDB方式是通过快照完成的，当符合一定条件时Redis会自动将内存中的所有数据进行快照并且存储到硬盘上。进行快照的条件在配置文件中指定，有2个参数构成：时间和改动的键的个数，当在指定时间内被更改的键的个数大于指定数值时就会进行快照。

在配置文件中已经预置了3个条件：

save 900 1  #15分钟内有至少1个键被更改则进行快照
save 300 10  #5分钟内至少有10个键被更改则进行快照
save 60 10000  #1分钟内至少有10000个键被更改则进行快照

以上条件之间是“或”的关系。

默认的rdb的文件路径是在当前目录，文件名是：dump.rdb，可以在配置文件中修改路径和文件名，分别是dir和dbfilename。

进行数据持久化的过程
Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，一般情况下1GB的快照文件载入到内存的时间约为20~30秒钟。（不同服务器会有差异）

RDB的快照过程如下：

• Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
• 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入到硬盘中的临时文件；
• 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件。

命令
可以通过SAVE和BGSAVE命令来手动快照，两个命令的区别是前者是由主进程进行快照，会阻塞其他请求，后者是通过fork子进程快照操作。

注意：由于Redis使用fork来复制一份当前进程，那么子进程就会占有和主进程一样的内存资源，比如说主进程8G内存，那么在备份的时候必须保证有16G的内存，要不然会启用虚拟内存，性能非常差。

3.Redis持久化之AOF

Redis的AOF持久化策略是将发送到Redis服务端的每一条命令都记录下来，并且保存到硬盘中的AOF文件，AOF文件的位置和RDB文件的位置相同，都是通过dir参数设置，默认的文件名是appendonly.aof，可以通过appendfilename参数修改。

• AOF，英文是Append Only File，即只允许追加不允许改写的文件。

• 我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

• 默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

• 如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。

• 在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性。

• 场景再现，操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。

• 如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

AOF文件修复
如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

• 备份被写坏的AOF文件
• 运行redis-check-aof –fix进行修复
• 用diff -u来看下两个文件的差异，确认问题点
• 重启redis，加载修复后的AOF文件

4.AOF重写

因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

参数
重写策略的参数设置：
auto-aof-rewrite-percentage 100
当前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据。
auto-aof-rewrite-min-size 64mb
限制了允许重写的最小AOF文件大小，通常在AOF文件很小的时候即使其中有些冗余的命令也是可以忽略的。

文件写入默认情况下会先写入到系统的缓存中，系统每30秒同步一次，才是真正的写入到硬盘，如果在这30秒服务器宕机那数据也会丢失的，Redis可以通过配置来修改同步策略：

 appendfsync always  每次都同步 （最安全但是最慢）
 appendfsync everysec  每秒同步  （默认的同步策略）
 appendfsync no  不主动同步，由操作系统来决定 （最快但是不安全）

AOF重写的内部运行原理

• 在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

• 与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

• 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

• 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。

5.对比

• RDB需要定时持久化，风险是可能会丢两次持久之间的数据，量可能很大。
• AOF每秒fsync一次指令硬盘，如果硬盘IO慢，会阻塞父进程；风险是会丢失1秒多的数据；在Rewrite过程中，主进程把指令存到mem-buffer中，最后写盘时会阻塞主进程。
• 在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

关于Redis主从架构、主从复制可以看这篇文章

https://blog.csdn.net/illusory_germ/article/details/100986264