redis学习笔记-持久化RDB和AOF

redis有两种持久化方式RDB(redis database)和AOF(append only file)

一、RDB

定义：每隔一段时间把内存中的数据生成快照保存到磁盘中，恢复时也是将快照文件直接读入到内存中；redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，持久化结束后用临时文件代替上次的文件；

优点：效率高；

缺点：最后一次持久化的数据可能会丢失；fork时占内存

rdb保存的是dump.rdb文件

保存策略：save <seconds> <changes>：指定时间内，数据变化的次数达到阈值，则保存一次

系统默认：

save 900 1：15分钟修改过至少1次

save 300 10：5分钟内修改过至少10次

save 60 10000：1分钟内修改过至少1万次

flushall（清空，不常用）或shutdown（关闭）或save（备份数据，全部阻塞）或bgsave（异步备份，可以同时处理数据）备份数据

redis-check-dump修复快照文件：redis-check-dump --fix dump.rdb

二、AOF

定义：以日志的形式来记录每个写操作，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据

优点：配置灵活。每修改同步，性能差但数据完整性比较好；每秒同步，如果一秒内宕机，会有数据丢失；不同步

缺点：相同数据量下aof的文件要大于rdb文件，恢复速度慢于rdb；aof运行效率要慢于rdb，每秒同步效率较好，不同步效率和rdb相同

aof保存的是appendonly.aof文件

默认是关闭的：appendonly no

同步策略Appendfsync：

Always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好

Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，数据会丢失（默认推荐）

No：不计

redis-check-aof修复日志文件：redis-check-aof --fix appendonly.aof

重写原理：AOF文件持续增长而过大时，会fork出来一条新进程来将文件重写（先写临时文件最后rename），遍历新进程的内存数据，每条记录有一条set语句，并没有读旧的aof文件，而是将整个内存中的数据用命令的方式重写一个新的aof文件，类似于快照

触发机制：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

auto-aof-rewrite-percentage 100（百分比）

auto-aof-rewrite-min-size 64M（大小值，生产会比较大）

三、总结

对数据完整性要求低，对要率要求高：开启rdb

对数据完整性要求高：开启aof

只做缓存使用：不启动持久化

正常可以两个同时开启，如果两个同时存在，优先使用aof加载数据

性能建议：

1、只在slave上支持rdb文件，而且只要15分钟备份一次就够了，只保留save 900 1

2、启用aof的好处是最多丢失2秒的数据。缺点是持续的IO；aof进行rewrite时将rewrite过程中产生的数据写到新的文件中会产生阻塞（类似JVM的STW）；应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小，可以设置到5G以上

3、不启用aof，仅靠master-slave replication实现高可用性能节省很多IO开销，也减少了rewrite造成的系统波动。代价是主从同时宕机，会丢失较长时间内的数据