Redis持久化RDB与AOF（笔记）

redis持久化
1.RDB
2.AOF

一.RDB,redis database
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshotting，它恢复时是将快照文件直接读到内存里。

Reids会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好文件。

整个过程中，主进程不进行任何IO操作，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB缺点是最后一次持久化后的数据可能丢失。

Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量，环境变量，程序计数器等）数值都和原进程一样，但是是一个全新的进程，并作为原进程的子进程。

RDB保存的是dump.rdb文件

配置位置：
redis.conf中SNAPSHOTTING
save <reconds> <changes> 指定在多长时间内发生多少次改变就将数据同步到数据库，生成dump.rdb文件。

dbfilename dump.rdb 设置备份恢复得dump.rdb文件名

redis-server重启后自动备份恢复

当输入命令 flushall或shutdown时迅速斩断内存情况，形成新的dump.rdb文件，所以需要对dump.rdb文件进行备份

redis-cli: save/bgsave 主动备份到dump.rdb，save时只管保存，其他全部阻塞。bgsav,redis在后台异步进行快照操作，同时响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间。

stop-write-on-bgsave-error save出错时停止写入

rdbcompression yes 指定存储至本地数据库时是否压缩数据，默认为yes。节省CPU时间可以关闭，但会导致数据库文件巨大。

rdbchecksum 在存储快照之后，redis使用CRC64算法来进行数据校验，但这样会增大10%的性能消耗，若希望获取最大性能可以关闭。

优势
1.适合大规模的数据备份恢复
2.对数据完整性和一致性要求不高
3.可以最大化redis的性能

劣势
1.在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
2.fork的时候，内存中的数据被克隆了一份，大致两倍的膨胀性需求考虑。

停止RDB
动态停止所有RDB存储规则：redis.cli： config set save ""

二.AOF append only file
以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。

AOF保存的是appendonly.aof

appendonly no 默认为关闭AOF

RDB和AOF可同时存在，但重启根据的AOF进行恢复，若appendonly.aof文件损坏则redis-server无法正常启动。

linux :redis.check-aof -fix appendonly.aof 修复aof文件

appendfsync
1.always 同步持久化，每次发生数据改变会立刻记录到磁盘，性能较差，数据完整性比较好。
2.everysec 默认推荐，异步操作，每秒记录，若一秒内宕机，有数据丢失。
3.no

rewrite 重写
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制。

当AOF文件的大小超过所设定的阙值，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也就是先写临时文件最后在rename）,遍历新进程的内存中数据，每条记录有一条的set语句。重写AOF文件的操作并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，这点和快照有点类似。

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

劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb，
aof运行效率慢于rdb，每秒同步策略效率较好

总结：
RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储。
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会执行这些命名来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
只做缓存：若只希望数据在服务器运行时存在，也可以不使用任何持久化方式。

性能建议：
1.因为RDB文件只用于后备用途，建议只在slave上持久化RDB文件，而且只要每15分钟备份一次就够了，只保留save 900 1 这条规则

2.若使用AOF，好处是在最恶劣的情况下也只会丢失不超过两秒的数据。代价一是带来了持续的IO，二是AOF Rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应尽量减少重写频率，AOF默认重写的基础大小可以设置到5G以上。

3.若不使用AOF，仅靠主从复制实现高可用性也可以。能省掉一大笔IO，也减少了重写时带来的系统被动。代价是Master/Slave同时倒掉，会丢失十几分钟的数据。启动脚本也要比较两个两个Master/Slave中的RDB文件，载入较新的那个。新浪微博曾选用这种架构。