RDB(redis data base)

将内存中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。

rdb流程如下，当触发了一次新的持久化操作，redis会fork一个主进程，该线程先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化好的文件。整个过程，主进程是不进行任何IO操作的，这确保了极高的性能，但是对于数据的完整性不敏感，有可能会丢失最后一次持久化的数据。

如何恢复RDB数据

1.将rdb文件移动到redis安装目录并启动服务，redis将会自动将文件中的数据读取到内存中
2.config get dir获取目录

save与bgsave的区别

有两种方式生成RDB文件，一种是用户输入save指令，手动生成快照文件（save）。
另外一种就是根据配置文件里的配置，当达到触发条件时（例如60秒执行一万次更新操作），生成快照文件(bgsave)。

save 命令会阻塞redis服务进程，直到RDB文件创建完毕为止。

bgsave命令则会创建一个新的线程，该线程fork自主进程，该进程负责生成快照文件，主进程继续处理命令请求。
bgsave由于克隆了一份主进程，使用bgsave时需要考虑内存占用翻倍的问题。

RDB适用场景

1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高
3.需要考虑bgsave时，内存占用翻倍的问题

AOF(append only file)

AOF是指redis以日志的形式记录每个读写操作，将redis执行过的所有写指令记录下来，只允许追加该日志文件，不允许改该日志文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOP保存的日志文件，默认为appendonly.aof文件

AOF重写机制

AOF采用文件追加方式，文件会越来越大，为避免出现此情况，新增了重写机制，当AOF文件大小超过设定的阈值，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof主动触发

AOF相关配置

// 开启AOF
appendonly yes
// 指定AOF日志文件名
appendfilename "appendonly.aof"
// 日志模式
// always: 同步模式，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整
// everysec: 默认配置，异步模式，每秒记录一次，如果一秒内宕机，有数据丢失，性能高，数据不完整
// no
appendfsync everysec
//  重写时是否可以用appendfsync,用默认no即可，保证数据完整
no-appendfsync-on-rewrite no
// 设置重写的基准值,默认配置是当AOF文件大小是上次rewrite后大小的一倍（100%），且文件大于64M时触发
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64MB

当同时存在AOF和RDB文件时，redis优先读取aof文件进行数据恢复

当AOF文件出现文损坏或文件部分内容不符合语法规范时，可以执行以下命令进行修复，该命令会将不符合语法规范的内容删除

redis-check-aof --fix appendonly.aof

AOF与RDB区别

区别

AOF与RDB策略建议

建议同时开启AOF与RDB，RDB用作后备用途，建议只在slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果开启AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可。代价一是带来持续的IO,二是AOF rewrite过程中产生的新数据写到新文件造成的阻塞是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64MB太小，可以设置成5G以上。默认超过原大小100%时重写可以改到适当的数值

不过不开启AOF,仅靠Master-Slave Replication实现高可用也可以。能减少大量的IO也减少了rewrite时带来的系统波动。代价是如果master-slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较master-slave中的rdb文件，载入较新的那个。新浪微博就选用了这种架构。