Redis 是内存数据库,数据存储在内存中,一旦服务器进程退出,数据就丢失了,所以 Redis 需要想办法将存储在内存中的数据持久化到磁盘。
Redis 提供了两种持久化功能:
SAVE
命令会阻塞 Redis 服务进程,直到 RDB 文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理任何命令请求。
BGSAVE
命令会派生出一个子进程,然后由子进程负责创建 RDB 文件,服务器进程(父进程)继续处理命令请求。
如果两个 key 值的修改具有事务性,需要手动加事务,不然备份时可能会导致两个值不一致。
除了主动执行命令,我们还可以通过 save 选项设置多个保存条件,只要任意一个条件满足,服务器就会执行 BGSAVE
命令:
save 900 1
save 300 10
save 60 10000
那么只要满足以下三个条件中的任意一个,BGSAVE
命令就会被执行:
只要打开 AOF 持久化功能,服务器在执行完一个写命令后,会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。
现代操作系统中,用户在写文件时,操作系统通常会将写入数据暂时保存在一个内存缓冲区里面,等到缓冲区被填满,或者超过了指定时限之后,才真正将缓冲区中的数据写入磁盘。这就有可能导致缓冲区内的数据还未写入磁盘,计算机发生停机,导致数据丢失。
appendfsync
选项的值可以决定 AOF 持久化功能的效率和安全性:
always
每次都同步到磁盘,效率低,安全性高;everysec
每隔一秒同步到磁盘,效率足够快,安全性高,只丢失一秒的数据;no
由操作系统控制同步到磁盘的时机,速度最快,安全性最低。因为 AOF 保存的是写命令,随着服务器的运行,同一个键值被操作的次数越多,单个键值就会产生多条写命令,AOF 文件就会越大,还原的时间就会越久。
为了解决 AOF 体积膨胀的问题,Redis 提供了 AOF 文件重写(rewrite)功能。
AOF 重写并不是对旧的 AOF 文件进行压缩。Redis 会从数据库中读出数据,生成对应的写命令,并写入新的 AOF 文件中,当新的 AOF 文件重写了所有数据的写命令,就可以替换掉旧 AOF 文件。
AOF 重写可以在后台进行,在重写过程中新产生的数据,会写入 AOF 重写缓冲区中,当重写结束再把缓冲区的写命令追加到新的 AOF 文件中即可。
RDB 文件的载入工作是在服务器启动时自动执行的,所以 Redis 没有专门用于载入的命令。
因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高,所以:
AOF 中包含了所有的写命令,服务器只要读入并重新执行一遍AOF文件里保存的写命令,就可以还原服务器关闭前的状态。
Redis 读取 AOF 文件并还原数据库状态的详细步骤: