Redis持久化

RDB快照（snapshot）

Redis配置默认情况下持久化使用的是RDB快照的方式，数据持久化存储的文件名为dump.rdb，数据持久化以二进制的方式保持在文件中。redis.conf中持久化的默认配置如下：

# If the background saving process will start working again Redis will
# automatically allow writes again.
stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

可以配置redis持久化的触发机制，让它在”N秒内数据集至少有M个改动“条件满足时，自动保存一次数据集。如redis.conf配置：

# Save the DB on disk:
#
#   save <seconds> <changes>
save 900 1
save 300 10
save 60 10000

还可以手动执行命令生成RDB快照，每次命令执行都会将所有redis内存快照到一个新的rdb文件里面，并覆盖原有的rdb快照文件。

127.0.0.1:6379> save
127.0.0.1:6379> bgsave

bgsave的写时复制（COW）机制

Redis借助操作系统提供的写时复制（Copy-On-Write），在生成快照的同时，依然可以正常处理写命令。Redis主线程fork出一个bgsave子线程，可以共享主线程的所有内存数据。bgsave子线程开始运行后，读取主线程的内存数据，并把它们写入RDB文件，此时如果主线程对这些数据都是读的操作，主线程和bgsave子线程互不影响。如果主线程修改一块数据，那么这块数据会被复制一份，生成数据副本，bgsave子线程会把这个副本数据写入RDB文件，而这个过程中，主线程仍然可以执行修改原来的数据。

save与bgsave对比

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis的其它命令	是	否（在生成子进程执行调用fork函数时会有短暂的阻塞）
复杂度	O(n)	O(n)
优点	不会消耗而外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

AOF（append-only file）

AOF持久化，将修改的每一条指令记录到文件appendonly.aof中，先写入os cache，每个一段时间sync到磁盘。可以通过修改Redis的配置文件redis.conf来开启AOF功能，开启AOF功能后，Redis重启时，就可以通过执行AOF文件中的命令来达到重建数据集的目的，在Redis的配置文件中还可以配置Redis多久将数据fsync到磁盘。

# 开启AOF 
appendonly yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# 数据同步刷新到磁盘配置
# 每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。
# appendfsync always
# 每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。
appendfsync everysec
# 从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。
# appendfsync no

AOF采用resp协议的数据格式将数据集存储到appendonly.aof文件中，如执行“set warrior 1” 对应aof文件记录的数据如下：

*3
$3
set
$7
warrior
$1
1

星号后面的数字代表命令有多少个参数
$号后面的数字代表这个参数有几个字符

AOF重写

AOF文件里面可能有太多没用的指令，所以AOF会定期根据内存中的最新数据生成aof文件，可以通过Redis的配置文件redis.conf中的两个配置项进行控制AOF自动重写的频率。

# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
# aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-percentage 100
# aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大
auto-aof-rewrite-min-size 64mb

AOF也支持手动重写，在redis客户端执行 bgrewireaof重写AOF， AOF重写redis会fork出一个子进程去做，不会对redis正常命令处理有太多的影响。

RDB与AOF的选择

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢失数据	根据策略决定

生成环境都可以启用，redis启动时如果既有rdb文件又有aof文件，则优先选择aof文件恢复，因为aof文件一般来说数据更安全一点。

Redis 4.0 混合持久化

Redis 4.0版本之后支持混合持久化配置，如果开启了混合持久化，AOF在重写时，不在单纯的将内存数据转换为resp格式命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令一起写入AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
# 必须先开启aof
aof-use-rdb-preamble yes  

Redis数据备份策略

1. 写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份

2. 每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份

3. 每次copy备份的时候，都把太旧的备份给删了

4. 每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏