Redis 持久化

Reids 持久化

Redis提供了两种不同的持久化方法来将数据存储到硬盘里面。

1. 快照(RDB)：
2. 只追加文件（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 文件都可以用于服务器重启时的数据恢复，具体流程如下图：