拆解 Redis 持久化 的工作原理

简介：

Hello 各位 ，我是公号「八点半技术站」的创作者 - Bruce.D （姓氏：豆）。

感谢微信给予的个人认证，专注于PHP、数据库技术领域知识经验分享。

技术的交流、不仅仅限制于阅读，在此欢迎各路大神、小白，来「wx技术群」分享自己的编程经验心得 与 技术实战干货。

Redis 持久化如何工作？

Q：首先要知道什么是持久化？

A：持久化就是将数据放到断电后数据不会丢失的设备中。（通常理解的硬盘）

Q：redis 在进行写操作，做了哪些事？

A：

（1）客户端向服务端发送写操作（数据在客户端内存中）；

（2）数据库服务端接收到写请求数据（数据在服务端内存中）；

（3）服务端调用 write 这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）；

（4）操作系统将缓存区中的数据转移到磁盘控制器上（数据在磁盘缓存中）；

（5）磁盘控制器将数据写入到磁盘物理介质中（数据真正落到磁盘中）。

Redis 持久化 之 RDB

RDB 的这种方式、是将 redis 某一刻的数据持久化到磁盘中，是一种 快照式 的持久化方式。

redis 在进行数据持久化过程中，会将数据写入到一个临时的文件中，带持久化过程结束了，才会用这个临时文件替换上次那个持久化好的文件。

因为这种特性，我们可以随时备份数据，快照的文件总是完整可用的。

我们可以通过 redis 的 save 指令来配置 RDB快照生成时机，例如：配置当10分钟以内有100次写入就生成快照，可以多个规则一起生成 。

（注：这些规则定义在redis 配置文件中，也可通过 redis 的 CONFIG SET 命令在redis 设置规则，无需重启 redis ）

对于 RDB 方式，redis 会单独创建（fork）一个子进程进行持久化。

而主进程不会进行任何 IO 操作的，这样确保了redis 极高的性能。

redis 的 RDB 文件不会坏掉，因为在写操作时候是在一个新的进程中的，当生成一个新的RDB 文件时，redis 生成的子进程会将数据写到另外一个临时文件中，然后通过原子性 rename 系统调用临时文件重命名为 RDB 文件。

这样在任何时候出现故障，redis 的 RDB文件总是可用的。

RDB 有一个缺陷：

就是数据库一旦出现问题，RDB文件保存的数据不是全新的。从上次 RDB文件生成到 redis停机这段时间的数据全部丢失了。

在部分业务下，RDB 方式还是可以接受。如果无法忍受数据丢失应用，就可以采用另外一个机制 ：AOF 日志。

Redis 持久化 之 AOF

AOF 全称：Append Only File （日志文件）

AOF 的这种方式、只允许追加不允许改写的文件。

（注：AOF 文件是可识别纯文本，它的内容就是redis的标准命令）

它这种方式，是将执行过的写指令记录下来，数据恢复是按照从前到后的顺序再将指令全部执行一遍。

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

./redis-server --appendonly yes

开启后，查看 cat appendonly.aof 记录所有写操作都会生成一条相应命令作为日志。

（注：每一条写入命令生成一条日志，会导致 AOF文件越来越大，因此redis提供了一个功能— AOF rewrite - 重新生成一份AOF文件）

简单说一下 AOF rewrite：

重新生成一份 AOF文件，新的 AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了怼同一个值的多次操作。

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

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

到这里也就结束了，首先恭喜你又阅读完一篇文章，如果你认为有收获那么收藏转发起来，帮助需要的伙伴。