什么是Redis持久化

Redis持久化简单概括为两点:

RDB (Redis DataBase)

AOF (Append Only File)

下面解释这两点:

RDB相关知识

RDB是在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话将的Snapshot快照, 它恢复时是将快照文件直接读到内存里。

Redis会单独创(fork)一个子进程进行持久化, 会先将数据写入到一个临时文件中, 待持久化过程结束了, 再用这个临时文件替换上次持久化好的文件。整个过程中, 主进程是不进行任何IO操作的, 这就确保了极高的性能。如果需要进行大规模数据的恢复, 且对于数据恢复的完整性不是非常敏感, 那RDB方式要比AOF方式更加高效。 RDB的缺点是最后一次持久化后的数据可能丢失。

保存的是dump.rdb文件, 在redis.conf中有一个SNAPSHOTTING行列块中的save可进行配置, save seconds changes 表示在指定时间内修改次数达到多少save一次，save “”为不备份。如果某数据非常重要, 需要备份但没有达到修改次数保存的条件, 那么直接使用save命令进行保存。

优势：适合大规模的数据恢复， 对数据完整性和一致性要求不高。

劣势：在一定间隔时间做一次备份，如果在redis意外宕机，就会丢失最后一次快照后的所有修改；Fork的时候，内存中的数据被克隆了一份，大致两倍的膨胀性需要考虑

如何停止：动态所有停止RDB保存规则的方法：redis-cli config set save “”。

那么问题来了！

RDB可以成功恢复数据，为什么还会出现AOF？引用德国哲学家黑格尔一句名言吧——凡是存在即是合理的。它的存在肯定是为了弥补老技术(RDB)的不足。

AOF相关知识

AOF是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件， redis启动之初会读取该文件重新构建数据，也就是说redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作，在redis.conf配置文件中的APPEND ONLY MODE列块中可配置。

aof文件与rdb文件共存，redis启动加载的是aof文件，redis.conf配置文件里也有说明

# AOF and RDB persistence can be enabled at the same time without problems.

If the AOF is enabled on startup Redis will load the AOF, that is the file

with the better durability guarantees.

AOF启动/修复/恢复：①正常恢复：I、启动：设置成YES(修改默认配置appendonly no改成appendonly yes)。II、将有数据的aof文件复制一份备份保存到相应目录(可通过redis-cli客户端使用命令config get dir查看)。III、恢复：重启redis然后重新加载。②异常恢复：I、启动：设置YES。II、备份被写坏的AOF文件。III、修复： 使用redis-check-aof –fix [需要被修复的aof文件的全路径]进行修复。IV、恢复：重启redis然后重新加载。

Rewrite重写：①、是什么? AOF采用文件追加方式导致文件会越来越大。为避免此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。②、重写原理：AOF文件持续 增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。III、触发机制：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64MB时触发(该数值可在redis.conf配置文件中找到，该数值需按实际生产上所需配置)。

①优势：I、每秒同步： appendfsync always 同步持久化 每秒发生数据变更会被立即记录到磁盘，性能较差但数据完整性较好。II、每修改同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失。III、不同步：appendfsync no 从不同步。②、劣势：针对数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。II、Aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

简单小总结一下AOF，见下图



总结一下RDB和AOF

①、 如果非常在意数据，又希望快速的恢复数据，可以简单的使用RDB。

②、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储。

③、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候回重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

④、只做缓存：如果只希望你的数据在服务器运行的时候存在，你也可以不适用任何持久化方式。

⑤、同时开启两种持久化方式：I、同时开启优先载入AOF文件来恢复原始的数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。II、RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

这篇文章整理花了double的时间，中途不小心点错关了，导致记录都没有了，发现自己真是愚蠢之极啊！这么低级的错误都能犯。。。过几天继续学习整理关于redis事务，消息订阅发布以及主从复制的知识。╮(╯▽╰)╭抽根烟思考思考人生，然后睡觉去了。