Redis入门——Redis持久化详解（RDB和AOF）

首先声明，本系列Redis博文内容是本人学习 【狂神说Java】Redis最新超详细版教程通俗易懂整理的学习笔记，本人也是初次接触Redis，水平有限，难免有错误不足之处，欢迎大家评论指正交流。

目录

Redis持久化

为什么需要持久化？

RDB（Redis DataBase）

APPEND ONLY FILE (AOF)

Redis持久化

为什么需要持久化？

Redis是内存数据库，如果不将内存中的数据状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据状态也会消失。所以Redis必须持久化！

RDB（Redis DataBase）

本质是将数据以快照的形式保存到磁盘上。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名为dump.rdb。恢复时从RBD文件读取数据放入内存中

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB缺点是 最后一次持久化后的数据可能会丢失（丢失最后一次快照的修改，临时文件会丢失）比如设置60S内更新n次才触发，结果第58s时宕机了，则此时数据更新丢失。

 

两种触发机制：1.自动触发；2.手动触发

    1.自动触发：配置文件中snapshoting部分，自动触发： 配置文件中的save规则，达到什么条件将数据保存到磁盘。

    2.手动触发：两种命令。save和bgsave

        1）save，该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止，对于多个客户端，显然不可取；

        2）bgsave，执行此命令时，Redis会在后台异步进行快照操作，同时还能响应其他客户端请求。具体操作时Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。 基本上Redis内部所有的RDB操作都是采用bgsave命令。

rdb文件产生：  1.save的规则满足的情况下，会自动触发RDB规则

                         2.执行了flushall命令，也会触发RDB规则，rdb文件是空的

                         3.退出redis，也会产生RDB文件

删除rdb文件，再次启动，数据丢失（Redis启动时使用rdb文件从磁盘读取数据，持久化的数据）

 

如何恢复数据： 只需要将rdb文件放在redis启动目录中就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据。

在redis端口下，可通过config get dir获取当前目录，如果该目录下存在dump.rdb文件，启动就会自动恢复其中的数据。

优点：

    1.适合大规模的数据恢复！

    2.对数据的完整性要求不高！

缺点：

    1.需要一定的时间间隔进行操作！如果redis意外宕机了，最后一次的修改数据就没了

    2.fork进程时，会占用一定的内容空间。

 

 

APPEND ONLY FILE (AOF)

将所有写操作记录下来，恢复的时候把这个文件全部执行一遍！

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录）， 只追加文件但不改写文件，Redis启动之后会读取该文件重新构建数据，换言之， Redis重启的话就根据日志文件的内容将指令从前到后执行一遍以完成对数据的恢复。

Aof保存的是appendonly.aof文件

Redis默认不开启AOF

appendonly no        #Redis默认不开启AOF
appendfilename "appendonly.aof"    #aof文件名

 

如果aof文件有错误，这时redis是启动不起来的，我们需要修复aof文件，使用redis-check-aof修复，修复命令：

redis-check-of --fix appendonly.aof.

如果修复成功，则重启成功。

如果qof文件大于64M，太大了，fork一个新的进程来将我们的文件进行重写（aof是无限制追加）

 

优缺点：

# appendfsync always    #每次修改都会同步，消耗性能
appendfsync everysec    #每秒同步一次，可能会丢失1s的数据
# appendfsync no      #不执行同步，这时操作系统自己同步数据

优点：

    1.每一次修改都同步，文件的完整性会更好！

    2.每秒同步一次，可能丢失一秒的数据

    3.设置从不同步，效率最高！

缺点：

    1.相对于数据文件来说，aof文件大于rdb，恢复数据也比rdb慢

    2.aof运行也比rdb慢，所以默认是rdb持久化

 

扩展：

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

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

    3） 只做缓存，如果只希望数据在服务器运行时存在，也可以不使用任何持久化。

    4）——同时开启两种持久化方式，Redis重启时优先使用aof文件来恢复原始数据，因为一般情况下aof数据更完整（记录每次操作再重头到位执行）。

      ——RDB数据不实时，同时使用两者，Redis优先找AOF文件。RDB更适合备份数据库，AOF在不断变化时不好备份，快速重启，而且不会有AAOF可能潜在的bug，留着作为一个万一的手段。

    5）性能建议：RDB文件只用作后背用途，建议只在slave上持久化RDB文件，一般设置只要15分钟备份一次就好，save 900 1