redis持久化机制

redis相较与Memcache具有支持多种数据类型以及持久化的优势，而redis的持久化主要通过RDB和AOF实现。
RDB
RDB：redis内存快照，具有时点性特点。
触发方式分为save、bgsave:
save:为前台阻塞运行，适用于服务器停机维护时使用。
bgsave:后台非阻塞运行，redis通过fork出子进程进行数据快照的保存，同时redis主进程使用copy-on-write(写时复制)的机制对外正常提供服务。
bgsave可以通过redis配置文件实现
save 900 1
save 300 10
save 60 100000
表示60秒时间内，如果操作次数达到100000次则触发bgsave，没有没达到并且时间超过了60秒则等时间到300秒判断炒作次数是否达到了10次，如果达到了触发bgsave，如果没有达到并且时间超过了300秒，则等事件到了900秒判断操作次数是否达到了1次，如果也没有则等时间达到900秒触发bgsave，注释掉save或设置为save ""则表示关闭了该配置。
RDB弊端：

1. 具有时点性，可能造成数据丢失（不是实时记录数据变化，时点与时点间窗口数据容易丢失）。
   RDB优点：
2. 恢复速度较快（类似于序列化反序列化过程）。
   AOF
   AOF（aapend only file）实现方式：redis的写操作记录到文件中。
   AOF优点： 丢失数据少。
   redis中RDB和AOF可以同时开启，但是如果开启了AOF则只会用AOF进行恢复。4.0以后AOF中包含RDB全量以及增加记录写的操作。
   AOF弊端： 体量无限变大 --> 恢复慢。
   针对这个弊端，redis4.0以前AOF重写（删除抵消的命令，合并重复的命令），redis4.0以后AOF重写（将老大数据RDB到AOF，然后将增量的以指令的方式append到AOF，这种方式利用了RDB的速度快以及AOF的数据全）。
   AOF可以通过redis配置文件实现：
   appendonly yes 开启aof
   appendfsync always 每笔写操作都触发
   appendfsync everysec 每秒触发（默认）
   appendfsync no 写操作写入buffer，知道buffer满才进行flush，可能会丢失buffer大小的数据。
   auto-aof-rewrite-percentage 100 redis会记录上一次rewrite后aof的大小，新增的大小达到64（100%）后会再次触发aof。
   auto-aof-rewrite-min-size 64mb 第一次aof文件达到64mb触发rewrite
   清空redis的数据文件，然后重启redis，执行命令set k1 aaa，打开
   appendonly.aof文件：
   
   dump.rdb文件为二进制，使用redis-check-rdb dump.rdb可以查看rdb文件的基本信息。
   通过BGREWRITEAOF命令可以触发AOF重写。