Reids 持久化
Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。
- 快照(RDB):
- 只追加文件(AOF):
两种命令可以同时使用,又可以单独使用,甚至在某些情况下两种方法都不使用,具体如何使用还需要根据场景来定
快照(RDB)
介绍
将某一时刻的所有数据写入硬盘里面,
系统崩溃造成的损失:
举个例子, 假设Redis目前在内存里面存储了10GB的数据,上一个快照时在 10:10创建的, 在15:10时,Redis又开始创建快照,并在15:12快照文件创建完毕之前,有35个键进行了更新。如果在15:10至15:12期间,系统发生崩溃,导致无法完成快照,那么Redis将丢失10:10之后的所有写入数据,如果系统恰好在新的快照文件创建完毕后崩溃,那么Redis将只丢失35个键的更新数据
配置选项
save 60 100 # 在几秒内改动了多少数据就触发持久化, 如: 60秒内有100个值变化,则保存,可设置多个
stop-writes-on-bgsave-error no # 备份进程出错主进程是否继续执行写操作
rdbcompression yes # 是否对快照文件进行压缩,推荐no 相对于硬盘成本cpu更值钱
dbfilename dump.rdb # 设置dump文件的位置
创建快照的方法:
- BGSAVE 目前基本上所有平台都支持,除windows平台, Redis会调用 fork 来创建一个子进程负责将快照写入磁盘,而父进程则继续处理命令请求
- SAVE 接到SAVE命令的Redis服务器在快照创建完毕之前将不再相应任何其他命令, SAVE命令并不常用,我们通常只会在没有足够内存去执行BGSAVE命令的情况下,又或者即使等待持久化操作执行完毕也无所谓的情况下,才会使用这个命令
- 配置文件配置 save 比如save 60 1000, 那么从Redis最近一次创建快照之后开始计算,当" 60秒之内有1000次写入" 这个条件被满足时,Redis自动触发BGSAVE命令。如果设置多个save配置选项,则满足其中一个时,就会触发BGSAVE
- SHUTDOWN 当redis接受到关闭服务器的请求时,会执行一个SAVE命令,阻塞所有客户端,不再执行客户端发送的任何命令,并在SAVE命令执行完毕后关闭服务器
- 主从复制 当一个Redis服务器连接另一个Redis服务器, 并向对方发送SYNC命令来开始一次复制操作的时候, 如果主服务器目前没有在执行BGSAVE操作,或者主服务器并非刚刚执行完BGSAVE操作,那么主服务器就会执行BGSAVE命令
只追加文件
介绍
执行写命令时,将执行的写命令复制到硬盘里面
系统崩溃造成的损失
在系统崩溃时,如果配置设置成 appendsync everysec
,则最多损失1秒的写入数据
命令
BGREWRITEAOF # 该命令会通过移除AOF文件中冗余命令来重写AOF文件,使AOF文件的体积变得尽可能地小
配置选项
appendonly no # 是否开启 aof 模式
appendfilename "appendonly.aof"
# 写入磁盘方式
# always:每个Redis写命令都要同步写入硬盘。这样做会严重降低Redis速度
# everysec: 默认,每秒执行一次同步,显式地将多个命令同步到硬盘
# no: 让操作系统来决定应该合适进行同步
appendfsync everysec
no-appendfsync-on-rewrite no # 对AOF进行压缩的时候是否执行同步操作
# 以下两个命令
# 当AOF文件的体积比上一次重写之后的体积大了至少一倍(100%)
# 并且AOF的文件体积大于 64MB时
# 执行BGREWRITEAOF命令进行压缩
auto-aof-rewrite-percentage 100 # 多久执行一次AOF压缩
auto-aof-rewrite-min-size 64mb # AOP超过10m就开始收缩
优缺点
- RDB
- 优点
RDB是一个紧凑压缩的二进制文件,代表Redis在某一个时间点上的数据快照。非常适合用于备份,全量复制等场景。比如每6小时执行BGSAVE
备份,并把RDB文件拷贝到远程机器或者文件系统中(如hdfs),用于灾难恢复。
Redis加载RDB恢复数据远远快于AOF方式。 - 缺点
RDB方式数据没办法做到实时持久化/秒级持久化。因为BGSAVE
每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题。
- 优点
- AOF
- 优点
AOF可以更好的保护数据不丢失。
AOF日志文件以append-only模式写入,写入性能比较高
AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。
适合做灾难性的误删除紧急恢复 - 缺点
对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大,恢复速度慢;
AOF开启后,支持的写QPS会比RDB支持的写QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fsync,性能也还是很高的;
- 优点
系统崩溃恢复
AOF 和 RDB 文件都可以用于服务器重启时的数据恢复,具体流程如下图: