Redis 是一个缓存工具,也叫做 NoSQL 数据库,既然是数据库,必然支持数据的持久化操作。在 Redis中,数据库持久化一共有两种方案:
Redis 使用操作系统的多进程机制来实现快照持久化:Redis 在持久化时,会调用 glibc 函数 fork 一个子进程,然后将快照持久化操作完全交给子进程去处理,而父进程则继续处理客户端请求。在这个过程中,子进程能够看到的内存中的数据在子进程产生的一瞬间就固定下来了,再也不会改变,也就是为什么 Redis 持久化叫做 快照。
在 Redis 中,默认情况下,快照持久化的方式就是开启的。
默认情况下会产生一个 dump.rdb 文件,这个文件就是备份下来的文件。当 Redis 启动时,会自动的去加载这个 rdb 文件,从该文件中恢复数据。
具体的配置,在 redis.conf 中:
# 表示快照的频率,第一个表示 900 秒内如果有一个键被修改,则进行快照 save 900 1 save 300 10 save 60 10000 # 快照执行出错后,是否继续处理客户端的写命令 stop-writes-on-bgsave-error yes # 是否对快照文件进行压缩 rdbcompression yes # 表示生成的快照文件名 dbfilename dump.rdb # 表示生成的快照文件位置 dir ./
在 Redis 运行过程中,可以向 Redis 发送一条 save 命令来创建一个快照。但是需要注意,save 是一个阻塞命令,Redis 在收到 save 命令开始处理备份操作之后,在处理完成之前,将不再处理其他的请求。其他命令会被挂起,所以 save 使用的并不多。
一般可以使用 bgsave,bgsave 会 fork 一个子进程去处理备份的事情,不影响父进程处理客户端请求。
定义的备份规则,如果有规则满足,也会自动触发 bgsave。
另外,当执行 shutdown 命令时,也会触发 save 命令,备份工作完成后,Redis 才会关闭。
用 Redis 搭建主从复制时,在 从机连上主机之后,会自动发送一条 sync 同步命令,主机收到命令之后,首先执行 bgsave 对数据进行快照,然后才会给从机发送快照数据进行同步。
与快照持久化不同,AOF 持久化是将被执行的命令追加到 aof 文件末尾,在恢复时,只需要把记录下来的命令从头到尾执行一遍即可。
默认情况下,AOF 是没有开启的。需要手动开启:
# 开启 aof 配置 appendonly yes # AOF 文件名 appendfilename "appendonly.aof" # 备份的时机,下面的配置表示每秒钟备份一次 appendfsync everysec # 表示 aof 文件在压缩时,是否还继续进行同步操作 no-appendfsync-on-rewrite no # 表示当目前 aof 文件大小超过上一次重写时的 aof 文件大小的百分之多少的时候,再次进行重写 auto-aof-rewrite-percentage 100 # 如果之前没有重写过,则以启动时的 aof 大小为依据,同时要求 aof 文件至少要大于 64M auto-aof-rewrite-min-size 64mb
同时为了避免快照备份的影响,记得将快照备份关闭
save "" #save 900 1 #save 300 10 #save 60 10000
手动备份命令
bgrewriteaof BGREWRITEAOF