谈谈Redis的持久化机制？

谈谈Redis的持久化机制？

因为Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，一旦服务器进程退出，服务器中的数据库状态也会随之消失，因此Redis提供了两种持久化机制：RDB、AOF。

• RDB

  在指定时间周期内把内存中的数据集快照保存到硬盘的二进制文件中，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。

  执行流程：Redis会单独创建一个子进程来进行持久化，然后先将内存中的数据集写入到一个临时文件中，等到持久化完成之后，再替换上次持久化好的文件，然后子进程退出，内存释放；在这个持久化过程中，主进程不参与任何IO操作，确保了高性能。

  • 触发条件

    （1）手动触发

    save命令和bgsave命令都可以生成RDB文件。

    • save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。
    • 而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

    （2）自动触发
    在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

  • 优点

    （1）只有一个文件 dump.rdb，方便持久化。

    （2）容灾性好，一个文件可以保存到安全的磁盘。

    （3）性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis的高性能)

    （4）相对于数据集大时，比 AOF 的启动效率更高。

  • 缺点

    数据安全性低：RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。因此RDB更适合数据要求不严谨的时候。

• AOF

  Redis会将每一个收到的写命令都通过Write函数追加到文件最后，因此会导致文件越来越大，对应的数据文件为 aof 文件。

  当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

  • 优点

    （1）数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。

    （2）通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof工具解决数据一致性问题。

    （3）AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)1

  • 缺点

    （1）AOF 文件比 RDB 文件大，且恢复速度慢。

    （2）数据集大的时候，比 rdb 启动效率低。

• Redis默认的持久化机制是RDB，RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

  但是由于AOF的优先级更高，因此当AOF和RDB同时开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。