redis通过RDB与AOF实现了数据持久化
1.RDB
rdb即redis database。redis数据库。当在redis中的数据储存满足配置文件中的要求时
（如图，分别是一小时修改一个键，5分钟之内修改100个键，1分钟只能有超过10000个键被修改），redis就会在redis的根目录下生成一个dump.rdb文件，这个dump.rdb文件就存储着这个时间段内修改过的键值对的信息。
当redis服务关闭，所有存放的信息都从内存中消失。当redis再启动时，会首先读取dump.rdb文件中的信息，重新将它们放入内存中。实现数据的持久化。
RDB的实现原理:
redis运行时，会创建一个进程用来进行持久化。该进程会将数据写入到一个临时文件中，持久化进程结束后。会用这次的临时文件替换上次的持久化文件。这样就可以保证主线程不进行任何IO操作，保证了效率。
RDB的触发:
1.满足配置文件中的情况
2.使用save（阻塞线程进行持久化）与bgsave(异步进行持久化，在后台进行)指令，立即进行持久化
3.使用FLUSHALL或FLUSHDB指令（无意义，因为保存的是空的数据）
RDB优点:
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高更适合使用
- 节省磁盘空间
- 恢复速度快
RDB劣势:
- Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
- 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
RDB配置策略:
stop-writes-on-bgsave-error? 无法进行备份时停止写入操作?：推荐设置为yes
rdbcompression 是否对rdb文件进行压缩:如果追求底cpu消耗的话就设置为no 如果追求底存储空间消耗的话就设置为yes
rdbchecksum 检查redis文件的完整性 占用一定的性能消耗，推荐设置为yes
2.AOF（append only file）
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认是关闭的，需要我们手动打开
执行流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always 一进行写操作就进行aof持久化 性能差数据完整性好,everysec 每秒进行一次持久化 当这一秒宕机时，该秒的数据会丢失,no 不主动进行持久化操作]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
aof的触发
1.进行写操作时
redis实现持久化的顺序
先AOF再RDB
aof的rewrite:当盛恒的aof文件过大(超过设定值默认为64MB且当aof文件比上次rewrite后扩大一倍)时，会进行rewrite来压缩aof文件的大小。只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
原理：
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
aof优点
- 备份机制更稳健，丢失数据概率更低。
- 可读的日志文本，通过操作AOF稳健，可以处理误操作。
aof缺点
- 比起RDB占用更多的磁盘空间。
- 恢复备份速度要慢。
- 每次读写都同步的话，有一定的性能压力。
- 存在个别Bug，造成恢复不能。
持久化文件的修复
当持久化文件被破坏时，可以用redis-check-aof/rdb --fix *.aof或*.rdb进行恢复。
?