redis数据持久化

数据持久化
redis 提供了将数据定期自动持久化至硬盘的能力， 包括 RDB 和 AOF 两种方案，两种方案分别有其长处和短板，可以配合起来同时执行，确保数据的稳定性。

必须使用数据持久化吗
redis 数据持久化是可以关闭的。如果仅仅当做缓存来用，可以关闭，毕竟这里的树都是其他拷贝
但通常来说，任然建议至少开始 RDB 方式的数据持久化，因为

• RDB 几乎不损耗redis的性能， rdb 进行持久化的时候， redis 主进程唯一需要做得事情是 fork 出一个子进程 ，所有的 持久化工作都是有子进程完成
• redis 无论什么原因挂掉之后，重启事能自动恢复到上一次RDB快照中记录的数据，这省去了手工从其他数据源同步数据的过程，二期要比其他任何的数据恢复方式都要快

RDB
采用RDB 的持久化方式，redis 会定期保存数据快照到一个 rdb 文件中，并在启动时自动加载 rdb文件，恢复之前保存的数据，可以在 redis.conf 中配置 redis 进行快照保存的时机

save [ seconds ] [changes]
意思是在 seconds 秒内如果发生了 changes 次数据修改，则进行一次 RDB 快照保存 
eg.  save 60 100
 

在 conf 文件中 可以配置多条 save 策略

save 900 1 
save 300 10 
save 60 10000

还可以通过手工 bgsave 命令触发 rdb 快照保存

下面说说 rdb 的优点

• 对性能影响小 子进程 操作 rdb
• 每次生成一个完整的 rdb 文件，作为非常可靠的灾难恢复手段
• rdb文件恢复数据比 aof 快很多

RDB 缺点是

• 快照是定期生成的，所以可能干好在 两次 rdb 之间 redis 挂了，那么这个自从上一次到这一次之间的数据，或多或少地会丢失部分数据
• 如果数据集非常的大 而且 CPU 不够强，Redis 是 fork 子进程时可能会消耗相对较长的时间，因此影响这期间客户端的请求。

AOF
采用 aof 持久化方式，redis 会把每一次的写请求都放在一个日志文件里，redis 重启的时候，会把 aof 文件中的记录的所有的写操作顺序的执行一遍，确保数据恢复到最新
aof 默认是关闭的，需要开启进行如下配置

appendonly yes

aof 提供了 3 中 fsync 配置 always 、everysec 、no

appendfsync no 不进行 fsync 将 flush 文件的时机交给 os 决定，速度最快
appendfsync always 每写入一条日志就进行一次的 fsync 操作，数据安全性最高，单数速度最慢
appendfsync 折中的做法，交给后台线程每秒 fsync 一次
 

随着 aof 不断的记录写操作日子，必定会出现一些无用的日志，例如某个时间点执行了 set key1 “abc” ，在此之后又执行了 set key1 “bcd”，那么第一条命令显然是没有用的，大量的无用日志会使得 aof 文件过大，也会让数据恢复的时间加长。基于这种情况，redis 提供了 aof rewrite 功能，只保留能够把书恢复到最新状态的最小写操作集。
aof rewrite 命令 可以通过 bgrewriteaof 命令触发，也可以通过 redis 定期自动执行。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min--size 64mb

两行的含义是  reids 在每次 aof  rewrite 时，会记录rewrite 后 aof 的大小，当 aof 日志在该基础上增长了 100% 后，自动进行 aof rewrite 操作，同时如果增长的大小没有达到 64mb则不会 rewrite

aof 的优点

• 安全性很高， appendfsync always 时候，任何写入的数据都不会丢失，但是这个策略一般不会使用，太慢了
• aof 在发生断电的时候也不会损坏，即使出现某条日志写入一半的情况，也可以使用 redis-check-aof 工具轻松修复
• aof 文件易读

aof 的缺点

• aof 的文件通常都比 rdb 文件大
• 性能消耗比 rdb 高
• 数据恢复比 rdb 慢