小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。
Redis 的数据全部在内存里,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失,这种机制就是 Redis 的持久化机制。
Redis 的持久化机制有两种,第一种是RDB快照,第二种是 AOF 日志。快照是一次全量备份,AOF 日志是连续的增量备份。快照是内存数据的二进制序列化形式,在存储上非常紧凑,而 AOF 日志记录的是内存数据修改的指令记录文本。
RDB
Redis持久化的几种方式——深入解析RDB - 王磊的文章 - 知乎
AOF
触发机制:
redis.conf中appendfsync来决定,always,everysec,no
AOF 重写
因为 AOF 持久化是通过保存被执行的写命令来记录 Redis 状态的,所以随着 Redis 长时间运行,AOF 文件中的内容会越来越多,文件的体积也会越来越大
为了解决 AOF 文件体积膨胀的问题,Redis 提供了 AOF 文件重写( rewrite) 功能。通过该功能,Redis 可以创建一个新的 AOF 文件来替代现有的 AOF 文件。新旧两个 AOF 文件所保存的 Redis 状态相同,但是新的 AOF 文件不会包含任何浪费空间的荣誉命令,所以新 AOF 文件的体积通常比旧 AOF 文件的体积要小得很多。
AOF 文件重写并不需要对现有的 AOF 文件进行任何读取、分析或者写入操作,而是通过读取服务器当前的数据库状态来实现的。首先从数据库中读取键现在的值,然后用一条命令去记录键值对,代替之前记录这个键值对的多条命令,这就是 AOF 重写功能的实现原理。
AOF 后台重写
fork子进程
AOF 重写缓冲区
讨论
RDB与AOF的优缺点:
- RDB 是一个经过压缩(LZF算法)的的二进制文件,代表 Redis 在某个时间点上的数据备份。非常适合备份,灾难恢复。
- RDB 恢复数据远远快于 AOF 的方式
- RDB 方式数据没办法做到实时持久化,而 AOF 方式可以做到。