redis持久化配置

• redis持久化

1：RDB(redis database)--快照
2: AOF(append only file)--日志

• RDB介绍

1：RDB是在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话将的Snapshot快照, 它恢复时是将快照文件直接读到内存里。
2：Redis会单独创(fork)一个子进程进行持久化, 会先将数据写入到一个临时文件中, 待持久化过程结束了, 再用这个临时文件替换上次持久化好的文件。整个过程中, 主进程是不进行任何IO操作的, 这就确保了极高的性能。如果需要进行大规模数据的恢复, 且对于数据恢复的完整性不是非常敏感, 那RDB方式要比AOF方式更加高效。 RDB的缺点是最后一次持久化后的数据可能丢失。
3：触发 save/bgsave

• AOF介绍

AOF是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件， redis启动之初会读取该文件重新构建数据，也就是说redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作，在redis.conf配置文件中的APPEND ONLY MODE列块中可配置

• RDB配置(SNAPSHOTING)

1:命令格式
save <seconds> <changes>
 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作，
 比如：900秒之内至少一次写操作、300秒之内至少发生10次写操作、60秒之内发生至少10000次写操作都会触发发生快照操作
save 900 1(900秒之内至少一次写操作)
save 300 10(300秒之内至少10次写操作)
save 60 10000(60秒之内至少10000次写操作)
*禁用RDB，save ""
2:文件名
dbfilename:dump.rdb(默认)
3：写配置
stop-writes-on-bgsave-error:yes(默认后台写错误则停止写快照文件)
4：rdb文件是否需要压缩
rdbcompression:yes(默认压缩)
5：rdb校验
rdbchecksum:yes(默认存储快照后，让redis使用CRC64校验)

• AOF配置(APPEND ONLY FILE)

1:开启AOF
appendonly：no(默人不开启，修改为yes开启)
2：文件名
appendfilename:appendonly.aof(默认)
3：同步持久化选项
appendsync:(always:同步持久化、everysencond:每秒、no:不开启)
4：rewrite
no-appendsync-on-rewrite:no(保持数据完整性)
auto-aof-rerite-min-size:100(基准大于1倍开始触发rewrite)
auto-aof-rewrite-percentage:64mb（文件大于64mb触发rewrite）

• 关于AOF的rewrite

AOF文件会越来越大，当文件大小超过设定的域值时，redis会启动AOF的文件内容压缩，只保留可以恢复的数据的最小指令集<bgrewriteaof>
1：原理
主进程会fork出一条新的进程对文件重写，遍历新进程的内存数据，每条记录有一条set语句。重写aof文件的操作并没有读取旧的aof文件，而是将整个内存的数据内容用命令的方式重写了一个新的aof文件
2:触发
配置文件中设置了aofrewrite策略、当aof的大小超过了设定的值、当有客户端要求rewrite操作时。redis会记录上次重写的AOF的大小，默认设置当前AOF文件大小是上次的rewrite后的大小的1倍且文件大于64mb
3:配置
no-appendsync-on-rewrite:no(保持数据完整性)
auto-aof-rerite-min-size:100(基准大于1倍开始触发rewrite)
auto-aof-rewrite-percentage:64mb（文件大于64mb触发rewrite）

• RDB注意事项

1：触发
save/bgsave
2：恢复
将dump.rdb移到redis启动目录即可
3：停止
redis-cli config set save ""
4:修复
redis-check-dump
**shutdown/flushall/save都会立即commit到dump.rdb，所以，一旦flushall，rdb文件就会清空内容

• AOF注意事项

1：触发
一旦AOF配置完成，重启就立即触发
2:恢复
重启redis重新加载
3：加载
如果aof和rdb同时存在，服务器启动，redis默认加载AOF
4：修复
redis-check-aof --fix appendonly.aof
**flushall也会写入到aof文件中，一旦恢复，所有数据将被清空

• RDB优缺

优点：
1：适合大规模的数据恢复
2：对数据的一致性和完整性要求不高
缺：
1：在一定时间内做一次备份，所以，如果Redis意外down掉，将会丢失最后一次快照的所有修改
2：fork的时候，内存中的所有数据被克隆了一份，所以，膨胀性需要考虑

• AOF优缺

优：
1：配置方便,默认的每秒写入机制，性能很好
2：数据的一致性和完整性高
3：rewrite机制，优化aof
4:误操作的恢复，如果误操作了flushall,在aof文件被重写之前，删掉最后的flushall命令，就可以恢复正常数据
缺：
1：aof文件相对而言要大于rdb
2: 恢复速度自然要慢于rdb