RDB持久化（redis database）
redis将当前时刻内存中所有的数据以快照方式写入一个默认为（dump.rdb）的二进制文件中。默认路径为当前redis的安装目录。当redis启动时，会自动加载这个文件进行数据的恢复。
触发方式
当redis进行RDB备份时，有两种触发方式
1，自动触发
我们在配置文件（redis.conf）中配置save这几项。
save 900 1 900秒内有一条数据被修改进行RDB
save 300 10 300秒内有10条数据被修改进行RDB
save 60 10000 60秒内有10000条被修改进行RDB
save "" 不进行RDB持久化2，手动出发
client端显式调用save或者bgsave命令redis进行RDB操作。
save操作是在主进程中进行RDB快照备份，他会阻塞我们的主进程进来的所有请求。当数据量较大时这会导致我们的应用程序的业务中断，所以不推荐使用save进行RDB持久化。
bgsave是redis主进程fork创建了一个子进程进行RDB操作。所以即使阻塞也只会阻塞创建子进程的这段时间。性能损失更小。
优缺点
RDB优点
1，文件占用空间小，因为redis默认会将我们的RDB文件进行LZF进行压缩。
2，恢复速度比AOF快。
RDB缺点
1，不能进行实时的持久化操作（无法秒级持久化）。因为每次持久化要创建一个子进程，这属于重量级操作，频繁使用会严重影响性能。所以也会导致两次间隔较长时间之间的数据丢失。
2，redis各个版本间的二进制文件格式可能不一致导致无法各个版本兼容。
AOF持久化（append only file）
redis将写操作写入一个appendonly.aof的文件中。
当我们启动redis时，他会将这个文件中记录的写命令重新执一次，迅速还原内存中的数据。
AOF操作有两个函数操作，一个是write函数一个fsync函数操作。
write函数会将写命令写入一个内存缓冲区，我们如果向将其真想写入文件还需要调用fsync函数。
这时候写入命令才真正的被写入AOF文件。
开启方式
配置文件：
我们在配置文件（redis.conf）中，打开appendonly
appendonly yes然后我们在找到# appendfsync配置
appendfsync always 每条写命令都进行一次AOF写入
appendfsync everysec 每一秒进行一次写入
appendfsync no 由系统自己决定何时进行AOF写入默认30S一次我们一般使用everysec。每个写命令进行一次写入会大大影响我们的redis性能。
AOF重写机制：
AOF会将我们对同一个key的多次操作只保留最终一个结果。以此来减少AOF文件的体积。
触发方式：
1，自动触发重写
配置文件：
auto-aof-rewrite-percentage 100 超过上一次aof重写aof文件大小的百分之多少，会再次优化，如果没有重写过，则以启动时为主
auto-aof-rewrite-min-size 64mb 限制了允许重写的最小aof文件大小2，手动触发重写
命令redis进行重写指令
bgrewriteaof当使用手动触发AOF重写时，会fork一个子进程，重建数据库状态，当完成后，会将这段时间内的新数据追加到子进程中进行AOF重写，当重写结束后会自动替换原有的AOF文件。
优缺点
AOF优点
我们可以配置appendfsync为everysec，将持久化操作限制到秒级。提高了整个数据库数据的完整性。如果有人误删了整个redis全部数据，flushdb或者flushall了，那么只要AOF没有被重写。我们只要找到AOF文件删除最后的清空操作，重启redis还是可以恢复数据的。
AOF缺点
1，因为是追加操作，所以redis的AOF文件会越来越大。虽然redis有重写AOF机制，只保留最小指令集的功能。他会将同一个key的多次修改只保留最终结果。但是还是会越来越大。
2，AOF因为是将写入命令重新再写一遍，所以AOF的恢复效率相对于RDB较低。
RDB和AOF同时使用
对于持久化redis建议我们两个持久化方式共同使用，但如果两个持久化方式都开启，我查到的资料中显示redis会率先加载AOF的进行数据恢复。
