持久化之RDB
RDB的持久化方式是在指定时间间隔，执行数据集的时间点快照。也就是在指定的时间间隔将内存中的数据集快照写入磁盘，也就是Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里面。
RDB保存的是dump.rdb文件。
自动触发
默认redis是有三种自动触发的规则，在配置文件中也有注释：
分别是一个小时内有一次变化，五分钟内有100次变化，一分钟内有10000次变化。如果要配置自己的规则，可以在配置文件中写一下语法：
save (time) (changes)
time指的是在多少时间内，单位是秒。
changes指的是变化次数，单位是次。
也可以在一行配置多个规则：
save (time) (changes) (time) (changes) (time) (changes)......
只要redis数据库中存在一定的变化满足了规则，就会进行一次快照
手动触发
手动触发分为两个指令：SAVE 和BGSAVE
只要执行了这两个指令，就会进行一次快照。
至于这两指令有和区别呢：
SAVE ：使用SAVE的时候，在保存快照文件期间，当前redis服务器会被阻塞，将不能正常进行缓存，因为会影响redis的功能的使用，所以通常这个指令不被推荐使用。
BGSAVE ：使用BGSAVE的时候，redis会fork出一个子进程来进行持久化，原来的主线程不会被影响，通常推荐使用这个指令
如果要想查看上一次快照的时间，可以使用LASTSAVE指令，步骤按如下：
RDB的优点和缺点
优点：
- 适合大规模的数据恢复
- 按时业务定时备份
- 对数据完整性和一致性要求不高
- RDB文件在内存中的加载速度要比AOF快得多
缺点：
- 如果Redis意外地down了，就会丢失从当前到最近一次的快照期间的数据，会导致快照文件的丢失
- 内存数据的全量同步，如果数据量太大，会导致IO严重影响服务器性能
- RDB依赖于主进程的fork，在更大的数据集中，可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，导致两倍的膨胀率
检查修复RDB文件的命令：redis-check-rdb (rdb文件的路径)
快照执行的情况：
- 配置文件中默认的快照规则
- 手动执行SAVE和BGSAVE命令
- 执行了flushall和flushdb命令，但是产生的快照文件是空的
- 执行shutdown且没有开启使用AOF
- 主从复制时，主节点自动触发
如何禁用快照：动态停止所有RDB保存规则的方法：redis-cli config set save ""
或者在配置文件中写一个 save ""
RDB优化配置项
在配置文件中：
- stop-write-on-bgsave-error：默认是yes，如果配置成no，表示不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接收新的写请求。建议使用yes
- rdbcompression：默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，redis会采用LZF算法进行压缩。如果不想消耗CPU来进行压缩的话，可以设置关闭次功能。建议使用yes
- rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增大约10%的性能消耗，如果希望获取到最大的性能提示，可以关闭此功能。建议使用yes
- rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下是no，此选项是禁用的
持久化之AOF
AOF（append only file）是以日志的形式来记录每个写操作，将Redis执行过的所有写的指令记录下来（读操作不记录），只许追加文件但是不可以更改文件，redis启动后会读取改文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认情况下，redis并没有开启AOF的开启AOF的功能需要设置配置文件中的appendonly为yes
AOF保存的是appendonly.aof文件
AOF工作流程
- Client作为命令的来源，会有多个源头以及源源不断的请求命令
- 在这些命令到达Redis Server后并不是直接写入AOF文件，会将这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁地磁盘IO操作
- AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件
- 随着写入AOF的内容的增加，为避免文件膨胀，会根据对着进行命令的合并（又称AOF的重写），从而起到AOF文件压缩的目的
- 当Redis Server服务器重启的时候会从AOF文件中载入数据
写回策略，可在配置文件中进行配置appendfsync，有以下三种：
- everysec：redis默认为这种方式，每秒写回，每个写命令执行完后，只是把日志写到AOF的内存缓冲区，没隔一秒把缓冲区中的内容写入磁盘
- always：同步写回，每个命令执行完后立即同步地将日志写回磁盘（性能影响大）
- no：由操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区写回磁盘（容易丢失数据）
在Redis6中，AOF文件分为三种类型：
base：标识基础AOF，一般由子进程通过重写产生，该文件最多只有一个
incr：表示增量AOF，一般会在AOFRW开始执行是被创建，该文件可能存在多个。
history：表示历史AOF，由BASE和INCR变化而来，每次AOFRW成功完成时，本次AOFRW之前对应的base和incr都将变成history，history类型的AOF会被Redis自动删除
为了管理这些AOF文件，引入了一个manifest文件来跟踪、管理这些AOF。同时，为了便于AOF备份和拷贝，我们将所有的AOF文件和mainfest文件放入一个单据的文件目录，目录名由appenddirname配置决定
AOF文件修复命令：redis-check-aof --fix (文件名)
AOF优缺点
优点：
- 使用AOF后Redis更加持久，使用每秒读入的方式是当出现异常时，只会出现一秒的数据丢失
- AOF日志是一个仅附加日志，不会出现寻道问题，不会因为断电出现损坏，如果因为一些原因出现写到一半结尾了，可以使用redis-check-aof工具来修复文件
- 当AOF变得太大时，可以在后台自动重写AOF。
- 格式易于理解和解析，易于恢复数据。
缺点：
- AOF文件通常比相同数据集的等效RDB文件大
- AOF运行效率要慢于rdb（everysec时）
AOF重写机制
由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断地进行，AOF文件会越来越大。文件越大，占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集
自动触发是默认为根据上次重写的AOF大小增长了一倍并且文件大小有64mb时自动进行重写
或者可以手动使用命令bgrewriteaof来重写
最小指令集的案例：
set k1 v2
set k1 v3
set k1 v4
最终只保留set k1 v4
重写原理
- 在重写开始前，redis会创建一个"重写子进程"，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
- 与此同时，主进程会将新接收到的指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
- 当"重写子进程"完成重写工作后，会给父进程发一个信号，父进程收到信号后就会将内存中的缓存的写指令追加到新的AOF中
- 当追加结束后，redis就会用新的AOF文件来代替旧的AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
- 重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，和快照有点类似
RDB+AOF混合持久化
如果同时开启RDB和AOF，重启时只会加载AOF文件，不会加载RDB文件，如果没有AOF就会加载RDB文件
当redis重启时，会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启只会找AOF，但是也建议不要只使用AOF，因为AOF在不断变化不好备份，RDB更适合用于备份数据库，留着RDB作为一个万一的手段
开启混合方式设置：设置aof-use-rdb-preamble的值为yes
混合持久化之后，RDB镜像做全量持久化，AOF做增量持久化
先使用RDB进行快照存储，然后使用AOF持久化所有的写操作，当重写策略满足或者手写触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两个部分恢复数据，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式
纯缓存模式
同时关闭RDB和AOF，Redis只做缓存功能。
在这种情况下，依然可以使用手动触发的方式使用AOF和RDB