Redis的持久化

如果Redis仅用作缓存，Redis中存储的所有数据都不是该数据的主体而仅仅是同步过来的备份，可以考虑不开启任何持久化，正常情况下建议至少开启RDB方式的数据持久化。

Redis的持久化分为两种，RDB和AOF。

1. RDB

RDB是通过一定时间间隔内检查数据变动次数是否超过指定值，若超过则保存当前Redis快照。

save [seconds] [changes] //意为在[seconds]秒内如果发生了[changes]次数据修改，则进行一次RDB快照保存

优点：

1. RDB持久化方式几乎不消耗Redis的性能，这种持久化方式会fork一个子线程来进行快照的保存，不影响主线程对客户端的响应。
2. RDB文件占内存相对较小。
3. Redis无论因为什么原因crash掉之后，重启时能够自动恢复到上一次RDB快照中记录的数据。这省去了手工从其他数据源（如DB）同步数据的过程，而且要比其他任何的数据恢复方式都要快。
4. 每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。

缺点：

1. 由于是在指定间隔期间检查数据变更次数来判断是否保存数据快照，所以当数据库崩溃时可能会有部分数据未丢失。
2. 当数据集非常大并且CPU性能不强（单核）的时候，fork子线程的时间会比较长，在此期间影响客户端的响应。

2. AOF

AOF将Redis的每次写操作记录到日志文件中，在Redis重启时将日志文件中的所有操作重新执行一遍，确保数据恢复到最新。

AOF默认是关闭的，通过appendonly yes指令开启。

AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：

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

由于Redis可能对同一个key做多次修改导致之前写操作被覆盖，这些被覆盖的写操作在数据恢复时是无用的，并且会使日志文件过大，所以Redis提供了rewrite功能。只保留能够把数据恢复到最新状态的最小写操作集。

AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：

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

上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。

优点：

1. AOF会将数据恢复到最新（appendfsync always）或最多丢失一秒内的数据（appendfsync everysec），对于容灾恢复来说安全性最高。
2. AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。
3. AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。

缺点：

1. AOF文件相对RDB文件更大
2. 性能消耗更高
3. 数据恢复速度更慢