redis(六) redis持久化

一、持久化分类

由于redis值存储在内存中，为了防止断电等特殊情况，需要将数据持久化到硬盘上进行备份。

redis持久化有两种方式： RDB 和 AOF

二、RDB持久化

RDB是一个二进制文件，在某个时间点将数据写入临时文件，持久化结束后用这个文件替换上一个文件，进行数据恢复。

优点：使用单独子线程，主线程不会进行任何IO操作，保证redis高性能。

缺点：RDB是间隔一段时间进行持久化，如果持久化期间发生故障，会丢失数据。所以这种方式更适合数据要求不严谨的情况。

这里间隔时间可以进行配置，通过配置redis在n秒内超过m个key被修改就执行一次RDB操作。这个操作类似在一个时间点保存一次所有redis数据，一次性快照所有数据。所以这个方法也叫做 snapshots。

RDB默认是开启的，配置如下：

#dbfilename 持久化数据保存在本地的文件名
dbfilename dump.rdb
#dir 持久化数据存在本地的路径，
dir ./
#snapshot触发时机 save
#可以通过 save 来关闭 snapshot
# 以下分别表示更改了1个key 时间隔900s进行持久化存储；更改了10个key 间隔300s进行存储；更改10000个key 间隔60s进行存储。 
save 900 1 
save 300 10 
save 60 10000
# 当snapshot出错时，是否阻塞客户端变更操作，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
# 是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网 络传输时间 
rdbcompression yes

三、AOF持久化

Append-Only File,将“操作+数据”以格式化指令方式追加到操作日志文件尾部，在append操作返回后（已经写入文件或将要写入）才进行实际数据变更，“日志文件”保存了历史所有的操作过程；当server需要数据恢复时，直接replay此日志文件，还原所有操作过程。AOF相对可靠，文件内容是字符串，容易阅读和解析。

优点：保持更高数据完整性，如果设置追加file的时间是1S，redis故障时，最多丢失1S数据。且日志如果写入不完整，支持redis-check-aof进行修复。aof没有被rewrite之前（文件过大时会对命令合并重写），可以删除其中的某些命令（如：误操作flushall）

缺点：AOF比RDB文件大，且恢复慢。

简单的理解AOF为日志文件，此文件只记录变更操作。（如set/del操作）如果server中持续大量操作，会导致aof非常庞大，意味着server失效后，数据的恢复过程将会很长；事实上，一条数据经过多次操作，会产生多条AOF记录，其实只要保存当前状态，历史操作是可以抛弃的，因为AOF持久化操作还伴生“AOF rewrite”

AOF的特性决定了它相对比较安全，如果你希望数据更少的丢失，可以使用AOF模式。如果AOF文件正在写入，server突然失效，有可能导致文件最后一次记录不完整，可以通过手工或者程序去检测并修正不完整记录，以便通过aof文件恢复正常。

aof默认关闭，如果要开启需要修改redis.conf：appendonly yes

#此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能
#只有在“yes”下，aof重写/文件同步等特性才会生效
appendonly yes
#指定aof文件名
appendfilename appendonly.aof
#指定aof操作中文件同步策略，三个合法值：always everysec no,默认：everysec
appendfsync everysec
#在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”
no-appendfsync-on-rewrite no
#aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建 议“512mb”
auto-aof-rewrite-min-size 64mb
#相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。
auto-aof-rewrite-percentage 100 

AOF是文件操作，对于变更比较频繁的server，必然造成磁盘IO的负荷加重；此外linux对文件操作采用“延迟写入”手段，并非每一次wirte都会触发实际磁盘操作，而是进入buffer中，当buffer达到阈值时触发写入操作(也有其他时机)。但这可能有隐患，如果buffer没有刷新到磁盘，此时物理机失效（如断电），那么可能导致最后一条或多条aof记录丢失。

AOF三种同步记录选项：

1. always：每条aof记录都立即同步到文件，这是最安全的方式，但是也带来更多磁盘操作和阻塞延迟，IO开支较大。
2. everysec：每秒同步一次，性能和安全都比较中庸，也是redis推荐方式，如果遇到物理机故障，有可能导致最近一秒内aof记录丢失（可能为部分丢失）
3. no：redis不直接调用文件同步，而是交给操作系统来处理。操作系统可以通过buffer填充情况或通道空闲时间择机触发同步，这是一种普通的文件操作，性能较好，当物理服务器故障时，数据丢失量与OS配置有关。

四、RDB与AOF区别

RDB是在某个时间点将数据写入临时文件，持久化结束后，用这个临时文件替换上一次持久化文件，达到数据恢复。

优点：使用单独子进程进行持久化操作，主进程不进行任何IO操作，保证了redis高性能。

缺点：RDB间隔一定时间进行持久化操作，如果持久化之间redis发生故障，会发生数据丢失，所以这种方式适用于数据要求不严谨时。

Append-Only File,将“操作+数据”以格式化指令方式追加到操作日志文件尾部，在append操作返回后（已经写入文件或将要写入）才进行实际数据变更，“日志文件”保存了历史所有的操作过程；当server需要数据恢复时，直接replay此日志文件，还原所有操作过程。AOF相对可靠，文件内容是字符串，容易阅读和解析。

优点：保持更高数据完整性，如果设置追加file的时间是1S，redis故障时，最多丢失1S数据。且日志如果写入不完整，支持redis-check-aof进行修复。aof没有被rewrite之前（文件过大时会对命令合并重写），可以删除其中的某些命令（如：误操作flushall）

缺点：AOF比RDB文件大，且恢复慢。