Redis持久化存储(AOF与RDB两种模式)

redis的持久化——RDB和AOF。redis有两种方式支持持久化，分别是RDB和AOF。
RDB
RDB即redis database，它是redis默认采用支持持久化的方式。RDB通过快照实现持久化的支持，当满足一定条件时，RDB将对内存中的所有数据生成快照，并存放到硬盘中，默认存放在当前执行redis服务的根目录的dump.rdb中。
先演示一下，创建5条K-V数据，会生成快照文件dump.rdb，由于一会儿这个文件会被覆盖，所以我们先复制一份，取名为dump_backup.rdm：
[图片上传中。。。（1）]
现在先删除当前的dump.rdb文件(没关系，我们已经备份了)，再进入redis服务，清除内存中的所有数据，并且关掉redis服务器。退出服务后会发现，当前目录下又生成了新的快照文件dump.rdb，但是由于我们清除了内存中的所有数据，所以这个快照文件中没有存放任何数据，一会儿真正起备份恢复作用的还是dump_backup.rdm文件。

由于redis默认会使用名为dump.rdb的文件进行恢复，所以我们现在先删除dump.rdb，然后将dump_backup.rdb重命名为dump.rdb，并且重启redis服务，进入redis会发现，数据自动恢复了：

RDB相关的配置在redis的配置文件redis.conf中，通常在标识有SNAPSHOTTING注释的模块下，我们可以在该配置文件中设置触发快照生成的情况，例如默认会触发快照生成的情况有，当900秒内有1个key被修改，或者当300秒内有10个key被修改，或者当60秒内有10000个key被修改，会触发快照的生成，如下图所示：

如果不希望将数据同步到快照文件中，可以设置为save “”。此外，当执行save，bgsave，flushall，shutdown命令时，也会生成快照文件dump.rdb。
redis生成快照文件的过程为：

1. redis会fork一个子进程作为主进程的副本;
2. 主进程负责接收并处理客户端请求，子进程负责将内存中的数据写入硬盘中的临时文件;
3. 待持久化过程结束后，会用此临时文件替换旧的dump.rdb，到此，一次快照生成完毕。
   不难理解，当还没有达到最后一次持久化结束的时间截点，而此时机器发生故障导致宕机，那么最后一次的数据就会丢失。
   此外，在redis.conf文件中，还有如下配置项：
   stop-writes-on-bgsave-error yes：当后台最后一次保存出错，停止redis的写操作。
   rdbcompression yes：当进行持久化时，是否对数据使用LZF算法进行压缩。
   rdbchecksum yes：在存储快照后，是否使用CRC64算法进行数据校验。
   dbfilename dump.rdb：指定生成的快照文件名为dump.rdb。
   dir ./：存储快照文件的路径，./表示当前路径，可以在进入redis服务后通过config get dir查看。
   RDB方式的优缺点如下：
   优点：
4. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快;
5. RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
   缺点：
6. 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点(save point)来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

7. 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端; 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
   AOF
   AOF即append only file，在AOF模式下，redis会将每一个收到的写命令(包括flushall命令)都通过write函数追加到文件appendonly.aof中。
   默认情况下redis并没有开启AOF，AOF的配置在redis.conf中注释为APPEND ONLY MODE的模块里，如果要开启AOF，需要将appendonly no改为appendonly yes。
   现在演示一下，复制一份redis.conf，重命名为redis_aof.conf，在这个文件中设置appendonly yes，并且指定以这个配置文件启动redis服务。

   
   
   

   在redis_aof.conf配置文件中，appendfsync指定了redis进行aof持久化的时机，有如下三种方式：
   appendfsync always：每次收到写命令就立即强制写入磁盘，性能最低，但是最能保证数据的完整性，不推荐使用
   appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
   appendfsync no：从不写入，完全依赖os，性能最好，不能保证数据的完整性
   redis默认采用appendfsync everysec，如下图所示：

   
   
   redis对aof新增了一种重写机制，当aof文件大小超过所设定的阈值时，redis会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof手动重写，redis配置的自动重写触发的情景如下：
   
   以上配置信息说明：redis会记录上一次重写时aof文件的大小，默认配置是当aof文件大小超过上次rewrite后大小的一倍且文件大于64mb时触发。如果启动redis后没有发生过重写，记录aof文件的大小就为启动时加载的aof文件大小。
   重写的原理：主进程会fork出一条新的进程对文件重写，遍历新进程的内存数据，每条记录有一条set语句。实际上，重写aof文件的操作并没有读取旧的aof文件，它只针对内存中当前存在的键值重写一个新的aof文件。