redis持久化方案

一、rdb方式

把数据生成快照保存到磁盘上，有手动触发和自动触发。

手动：

save 阻塞命令 ，bgsave 新开子线程进行处理，不阻塞主进程

命令：config set dir /usr/local  //设置rdb文件保存路径    备份：bgsave  //将dump.rdb保存到usr/local下    恢复：将dump.rdb放到redis安装目录与redis.conf同级目录，重启redis即可    

优点：1，压缩后的二进制文，适用于备份、全量复制，用于灾难恢复          2，加载RDB恢复数据远快于AOF方式    

缺点：1，无法做到实时持久化，每次都要创建子进程，频繁操作成本过高          2，保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题

自动：一下条件会触发rdb文件生成

900s内有一次数据修改

300s内有10次数据修改

60s内有10000次数据修改

二、aof方式

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决   开启：redis.conf设置：appendonly yes  (默认不开启，为no)   默认文件名：appendfilename "appendonly.aof"

appendonly yes           //启用aof持久化方式

# appendfsync always //每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec //每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐

# appendfsync no         //完全依赖os，性能最好,持久化没保证（操作系统自身的同步）

no-appendfsync-on-rewrite  yes  //正在导出rdb快照的过程中,要不要停止同步aof

auto-aof-rewrite-percentage 100  //aof文件大小比起上次重写时的大小,增长率100%时,重写

auto-aof-rewrite-min-size 64mb   //aof文件,至少超过64M时,重写

 

总结：真正生产环境，可以使用两种方式结合，默认首先利用aof进行数据恢复，但是aof备份文件有可能会出现编码版本不兼容，读取错误的情况，这时候可以用rdb在进行补救性的恢复