redis持久化知识汇总

主要分两个持久化方式RDB和AOF

RDB

RDB是以快照的形式将数据写入二进制文件，可以通过save和bgsave触发，也可以自动化

Save方式是直接在主进程进行持久化操作，缺点就是会导致阻塞服务器。

Bgsave方式会先创建子进程，在子进程中进行持久化操作，不影响主进程，但是持久化期间也不能接受主进程新的数据更新命令。

优势

（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

劣势

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，bgsave存储方式会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

AOF

AOF持久化是将每一天的redis数据更新命令写入AOF文件

触发规则（AOF默认everysec规则。）：

always 每次执行缓存命令都会执行，写入AOF文件。

everysec 每秒执行一次同步，异步操作，如果一秒内宕机，就会有数据丢失。

no 表示不主动同步，由系统完成操作，每30秒执行一次同步。

优势

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

劣势

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

RDB文件的载入和AOF文件的载入比较

RDB文件在服务器启动时自动载入，只要检测到RDB文件就自动载入并处于阻塞状态，直到载入完成。
AOF文件的优先级高于RDB文件，如果服务器开启了AOF持久化功能，则在重启时会加载AOF文件，而不是RDB。（AOF通常更新频率高于RDB文件）
如果AOF持久化关闭，才回去找RDB文件。

RDB快照的配置

save 900 1      // 900内,有1条写入,则产生快照save 300 1000   // 如果300秒内有1000次写入,则产生快照save 60 10000  // 如果60秒内有10000次写入,则产生快照

stop-writes-on-bgsave-error yes  // 后台备份进程出错时,主进程是否停止写入rdbcompression yes    // 导出的rdb文件是否压缩rdbchecksum   yes //  导入rbd恢复数据时，是否验证rdb的完整性dbfilename dump.rdb  //导出来的rdb文件名dir ./  //rdb的放置路径

AOF日志的配置

appendonly no # 是否打开 aof日志功能appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢#appendfsync everysec # 折衷方案,每秒写1次#appendfsync no      # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,no-appendfsync-on-rewrite  yes: # 正在导出rdb快照的过程中，是否停止同步aofauto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,才重写