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协议 详见