Redis 是个基于内存的数据库。那服务一旦宕机,内存中数据必将全部丢失。所以丢失数据的恢复对于 Redis 是十分重要的,我们首先想到是可以从数据库中恢复,但是在由 Redis 宕机时(说明相关工作正在运行)且数据量很大情况下,从数据库恢复的话,会为数据库带来巨大的压力,进而导致程序相应缓慢。因此实现数据的持久化,避免从后端数据库中恢复数据,对于Redis 是十分必要的。
此外,Redis 可以通过创建快照来获得存储在内存里面的数据。创建快照之后,可以对快照进行备份,可以将快照复制到其他服务器从而创建具有相同数据的服务器副本(Redis 主从结构,主要用来提高 Redis 性能),还可以将快照留在原地以便重启服务器的时候使用,其中 Redis 最常用的快照持久化机制分为两种,即 RDB 与 AOF。
1、Redis 持久化机制 RDB
RDB 持久化可以手动执行也可以根据配置定期执行,它的作用是将某个时间点上的数据库状态保存到 RDB 文件中,RDB 文件是一个压缩的二进制文件,通过它可以还原某个时刻数据库的状态。由于RDB文件是保存在硬盘上的,所以即使 Redis 崩溃或者退出,只要 RDB 文件存在,就可以用它来恢复还原数据库的状态。
可以通过 SAVE 或者 BGSAVE 来生成 RDB 文件:
- SAVE 命令会阻塞 Redis 进程,直到 RDB 文件生成完毕,在进程阻塞期间,redis 不能处理任何命令请求,这显然是不合适的。
- BGSAV E则是会 for k出一个子进程,然后由子进程去负责生成 RDB 文件,父进程还可以继续处理命令请求,不会阻塞进程。
2、Redis 持久化机制 AOF
AOF 和 RDB 不同,AOF 是通过保存 redis服务器所执行的写命令来记录数据库状态的。
AOF 通过追加、写入、同步三个步骤来实现持久化机制。
- 当 AOF 持久化处于激活状态,服务器执行完写命令之后,写命令将会被追加 append 到 aof_buf 缓冲区的末尾
- 在服务器每结束一个事件循环之前,将会调用 flushAppendOnlyFile 函数决定是否要将 aof_buf 的内容保存到AOF文件中,可以通过配置 appendfsync 来决定。
- always:aof_buf 内容写入并同步到 AOF 文件
- everysec:将 aof_buf 中内容写入到 AOF 文件,如果上次同步 AOF 文件时间距离现在超过1秒,则再次对 AOF 文件进行同步
- no:将 aof_buf 内容写入AOF文件,但是并不对 AOF 文件进行同步,同步时间由操作系统决定
- 如果不设置,默认选项将会是 everysec,因为 always 来说虽然最安全(只会丢失一次事件循环的写命令),但是性能较差,而 everysec 模式只不过会可能丢失1秒钟的数据,而 no 模式的效率和 everysec 相仿,但是会丢失上次同步 AOF 文件之后的所有写命令数据。
3、Redis 持久化机制 RDB 与 AOF 的区别
- 实现方式:RDB 持久化是通过将某个时间点 Redis 服务器存储的数据保存到 RDB 文件中来实现持久化的;AOF持久化是通过将 Redis 服务器执行的所有写命令保存到 AOF 文件中来实现持久化的;
- 文件体积:由上述实现方式可知,RDB 持久化记录的是结果,AOF 持久化记录的是过程,所以 AOF 持久化生成的 AOF 文件会有体积越来越大的问题,Redis 提供了 AOF 重写功能来减小 AOF 文件体积;
- 安全性:AOF 持久化的安全性要比 RDB 持久化的安全性高,即如果发生机器故障,AOF 持久化要比 RDB 持久化丢失的数据要少。因为 RDB 持久化会丢失上次 RDB 持久化后写入的数据,而 AOF 持久化最多丢失1s之内写入的数据(使用默认everysec 配置的话);
- 优先级:由于上述的安全性问题,如果 Redis 服务器开启了 AOF 持久化功能,Redis 服务器在启动时会使用 AOF 文件来还原数据,如果 Redis 服务器没有开启 AOF 持久化功能,Redis 服务器在启动时会使用 RDB 文件来还原数据,所以 AOF 文件的优先级比 RDB 文件的优先级高。
- | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
文件大小 | 小 | 大 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定
|