Redis持久化
【1】概念
Redis所有的数据存储在内存中，为了保证重启后，redis数据不丢失，需要把redis数据保存在磁盘中。
【2】持久化使用方式策略
（1）RDB 方式：默认支持，不需要配置
在指定的时间间隔内，将redis 内存中的数据集快照写入到磁盘当中去，比如每隔30S写入一次。
（2）AOF方式
以日志的形式记录服务器所处理的的每一个操作，在服务器启动之初，会读取该文件来重新构建redis数据库数据，以此来保证重启后数据库的数据是完整的。
（3）不持久化
单纯做缓存用
（4）RDB+AOF 同时使用
【3】两种核心方法
（1）RDB
优势：
（1.1）整个redis数据库只包含1个文件
（1.2）对于灾难恢复而言，可以通过拷贝压缩等传输到异地机
（1.3）性能最大化：在开始持久化的时候，只需要分一些进程，接下来就可以由子进程完成持计划的工作。
可以避免服务器进程进行持久化操作。数据量大的时候，恢复速度很快。
劣势：
（1.1）对于高可用性和数据安全性而言：会丢失一个间隔内的数据，比如30秒一次持久化，但28秒的时候宕机了，那么就会丢自上一个备份后的28秒的所有操作。
（1.2）当数据集非常大的时候，需要服务器停止一点时间甚至超过1s
基本操作与配置：
（1.1）默认的存盘配置如下（大概在文档15%的位置）
如英文描述一样。
save num1_second num2_key 每num1秒中，有num2个key有修改，则存盘
这里的默认就是每900/300/60 秒 有 1/10/10000 个 key 被修改，就存盘。
（1.2）默认redis数据库文件名称与存放路径（大概在文档15%的位置）
上面是文件名，下面是上面文件所在的路径， ./的意思就是，和当前打开的配置文件同一路径。
（2）AOF
优势：
（2.1）3种同步策略
《1》每秒同步：异步持计划，效率高，会丢失1S内数据
《2》每修改同步：同步持久化，效率低，不会丢数据
《3》不同步
（2.2）日志文件
《1》文件写入形式：使用的是append追加方式，如果宕机不会被破坏已经写入的数据。
《2》宕机恢复：如果一个命令写到一般就宕机了，可以用 reids-check-aof 工具来解决数据一致性问题。
《3》重写机制：如果日志文件过大，redis可以自动启用循环重写机制，redis以append的方式把最新操作数据写入到最老的日志文件中，同时redis还会创建一个新的文件来记录此期间哪些修改命令被执行了。因此在进行重写切换的时候，可以更好的保证数据那权限。
《4》可读性强：日志文件记录了很详细的修改操作记录和数据，可以用此文件重建数据库。
劣势
（2.1）文件大小：AOF比RDB文件大许多
（2.2）执行效率：每次操作都需要记录，比起RDB每过一段时间批量持久化记录，要慢不少。
（2.3）需要额外配置：
默认是关闭的，如果要启用则要把下图中第1行改成 yes，开启后下面就是文件名。
最后面的3行是同步策略，always 是修改后就立马同步，everysec 是每一秒，另外一个是不同步
