Redis 数据持久化

概述

Redis 主要用途是在内存中存储数据，对数据的存储就需要有可靠性，不会出现数据的丢失和错误。但我们都知道 Redis 的高性能来源于其将数据存储在内存中，一旦应用进程关闭（这可能是应用进程崩溃、或服务器主机异常引起的意外中断）会导致数据丢失。这时候数据的持久化就显得尤其重要了，数据持久化是指将内存中的数据备份在磁盘中一份，当下次启动 redis 时会从磁盘中读取数据，写入内存，从而实现数据的恢复。
Redis 的持久化有两种方式 RDB 和 AOF，RDB 是将内存数据集的快照主动或被动的按某些条件备份到磁盘中；AOF 是将 Redis 所有的数据更改命令存储在文件中，当下次启动 Redis 时就会执行文件中的所有命令来达到还原数据的效果

RDB 持久化

RDB 数据的备份分为手动和被动两种方式

手动触发

使用 save 命令可以手动触发备份数据

save 命令会阻塞 Redis 服务器进程，直到 RDB 的文件创建完成，期间不能执行其他任何命令请求。

如果希望不阻塞 Redis 服务器进程，可以使用bgsave 命令

bgsave 命令会创建一个子进程，由子进程来创建 RDB 文件，父进程可以继续处理其他请求。

这时我们就可以在 Redis 安装目录下看到 dump.rdb 文件，当下次启动 Redis 时就会加载改文件的数据

被动触发

被动触发是指达到一定的条件时，Redis 会自动备份数据。
在 Redis 的配置文件 Redis.conf 中我们可以看到如下配置

其中的含义分别为：

save 900 1 在900秒内发生一次数据变更执行备份

save 300 10 在300秒内发生10次数据变更执行备份

save 60 10000 在60秒内发生10000次数据变更执行备份

AOF 持久化

Redis 服务器默认开启 RDB，关闭 AOF。要开启 AOF 备份，需要修改配置文件。
设置配置文件中的 appendonly 为 yes

更改完配置文件后重启 Redis 服务，我们可以在安装目录下看到 appendonly.aof 文件，当我们执行添加、更改和删除数据命令时，Redis 会将命令写入 appendonly.aof 文件中。

重启服务后，依然可以 get 到改数据

两种持久化的选择

RDB 与 AOF 的区别

RDB 方式

优点：RDB 的数据保存文件紧凑，体积小，网络传输快，适合全量复制；RDB 的数据恢复速度要比 AOF 快很多。RDB 持久化对 Rdis 性能的影响较小。

缺点：RDB 文件的致命缺点就是数据的持久化无法做到实时保存，会出现数据丢失，这对系统中的重要数据来说是致命的。

AOF 方式

优点：AOF 持久化支持秒级的持久化，数据可实时保存。

缺点：备份文件大，启动时数据恢复慢，对 Redis 的性能影响大。

实际应用中应该如何选择

无论是 RDB 还是 AOF，开启持久化必然对性能方面造成一定的影响。从应用需求和硬件条件综合来考虑。

下面分场景来讨论持久化策略的选择，下面的讨论也只是作为参考，实际方案可能更复杂更具多样性。

（1）如果Redis中的数据完全丢弃也没有关系（如Redis完全用作DB层数据的cache），那么无论是单机，还是主从架构，都可以不进行任何持久化。

（2）在单机环境下（对于个人开发者，这种情况可能比较常见），如果可以接受十几分钟或更多的数据丢失，选择RDB对Redis的性能更加有利；如果只能接受秒级别的数据丢失，应该选择AOF。

（3）但在多数情况下，我们都会配置主从环境，slave的存在既可以实现数据的热备，也可以进行读写分离分担Redis读请求，以及在master宕掉后继续提供服务。

在这种情况下，一种可行的做法是：

master（主服务器）：完全关闭持久化（包括RDB和AOF），这样可以让master的性能达到最好

slave（从服务器）：关闭RDB，开启AOF（如果对数据安全要求不高，开启 RDB 关闭 AOF 也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并标记好备份的时间）；然后关闭 AOF 的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨12点）调用 bgrewriteaof。

本作品采用《CC 协议》，转载必须注明作者和本文链接