RDB

rdb是redis默认的持久化方案 在指定次数的写操作时，会将内存的快照(snapshot)的数据写入到磁盘。读取时也是读快照恢复

redis.conf文件对应 SNAPSHOTTING部分

1.save <seconds> <changes> # save<指定时间间隔><指定操作次数>
# save “”
save 900 1                       # 900秒内有一个操作 save一下
save 300 10
save 60 10000        

2. 指定文件名。default为 dump.rdb
dbfilename dump.rdb

3 文件存放路径
dir ./

4.默认开启数据压缩
rdbcompression yes
5.stop-writes-on-bgsave-error yes
当redis无法写入磁盘时，直接关掉redis的写操作

　如何执行

(bgsave)redis会单独fork一个子进程来进行持久化，先将一数据写入一个临时文件中，待整个持久化过程结束，再用这个临时文件替换掉上次持久化好了的文件,而父进程可以继续处理客户端请求。

(save) 这是阻塞式的存储，客户端无法连接redis，等save完成后 主进程接到子进程的信号，才开始工作。

优点：由于保存文件是内存的快照，所以这种在恢复时非常快，适用于备份和灾难恢复。

生成rdb文件的时候 主进程不会受到干扰。

由于保存的是内存快照，文件较小。

缺点：rdb没法实时持久化，因为每次bgsave都要 fork子进程 属于重量级操作，导致在上一次快照后的数据丢失。

rdb使用二进制格式保存，多个rdb版本易造成不兼容

因为使用fork 写时复制 所以在子进程复制的时候 如果 父进程在原有键上修改 会创建新的空间，若此时空间不够，会写入失败或者lru。-----（不确定）

AOF

以日志的形式来记录每个写操作(只能追加不能改写)、redis重启的话就会根据该文件构建数据。

每有一个客户端执行了一条写操作，就在aof文件后append一条。读不予理会。

配置文件:

1.appendonly no
redis默认关闭aof 开启需要把no改为yes

2.appendfilename “appendonly.aof”
指定文件名

3.appendfysnc [always|ererysec|no]
指定日志更新条件
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全） 
everysec：出厂默认推荐，每秒异步记录一次（默认值） 
no：不同步

AOF的重写机制

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

配置:

auto-aof-rewrite-percentage 100   ---一倍
auto-aof-rewrite-min-size 64mb    ---最小64mb

优点：数据的完整性跟一致性较高，日志文本可读，可以在日志文件上修改处理误操作。

缺点：AOF记录内容多，数据备份恢复会变慢，每次都同步写入对性能有较大影响。

当aof与rdb同时开启时，重启后默认加载aof文件。

Redis的aof 和 cli与server通信 通过 RESP协议 详见