Redis的持久化机制

多级缓存使用到了一个装饰设计模式：相当于我不影响我之前缓存本身的代码，但是我可以对我的缓存去做增强，因此多级缓存就是采用装饰模式去实现的~！

多级缓存可以采用装饰模式去重构~！

Redis当中的持久化机制：Redis当中提供了持久化机制，它会把内存当中的数据备份在磁盘当中！磁盘当中的文件当你出现断电、宕机之后，在你重启Redis时，它会把磁盘当中的文件再加载到内存当中，从而保证你的数据可以不丢失！

持久化机制可以保证即使Redis进程在写入数据时崩溃，数据也不会丢失~！

Redis的持久化机制有两种方案：RDB和AOF！

持久化机制 - RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照，是Redis默认的持久化方式。
简单来说就是把/将Redis内存当中的所有数据以二进制形式都记录/保存到磁盘当中，当Redis实例发生故障重启后，此时会从磁盘读取快照文件并加载到内存当中，从而来恢复数据。
Disk：磁盘 DB loaded from disk
RDB备份文件：dump.rdb => 保存的都是二进制形式的数据
快照文件称为RDB文件，保存了最后一次生成快照时Redis当中的所有数据，默认是保存在当前运行目录！

RDB持久化的执行时机

RDB持久化在四种情况下会执行：被动操作(一二三) + 主动操作(四)

一和二都是手动触发快照操作，让Redis去做一个备份！

手动调用执行save命令，可以立即执行一次RDB：DB saved on disk：保存在磁盘上，save指令是由Redis的主进程来执行RDB备份操作，由于Redis的工作线程是单线程，如果执行save指令则会阻塞其他所有命令的执行，因此不建议使用！只有在数据迁移时可能用到Redis为了规避这个问题，又给我们提供了另外一个指令：bgsave！
手动调用执行bgsave命令，异步执行RDB：bg指的是background，后台运行，bgsave指令会开启独立的子进程来执行RDB备份操作，从而避免主进程受到影响，主进程可以持续处理用户请求，不受影响。
Redis停机(关闭Redis服务器)时会执行一次save命令，执行RDB备份操作，实现RDB持久化：Saving the final RDB snapshot before exiting. 在退出之前保存最后的RDB快照。但是注意：如果突然断电则不执行RDB备份操作，主动关闭Redis服务器才会执行~！

4. 触发RDB条件时：在Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

RDB：把内存当中的数据直接备份到RDB文件当中~！

# 900秒内，如果至少有1个key被修改，则执行bgsave命令来指定RDB备份操作 如果是save "" 则表示禁用RDB
save 900 1  如果900s内有一个Key发生变化被修改,就触发一次RDB
save 300 10 如果300s内有十个Key发生变化,就触发一次RDB
save 60 10000 如果60s内有一万个Key发生变化(代表60s内至少执行10000次修改责编触发RDB),就触发一次RDB

RDB的其它配置也可以在redis,conf文件中设置：

# 是否对RDB备份文件做压缩处理,降低RDB文件的体积
# 建议不开启,压缩也会消耗cpu,影响Redis的性能磁盘的话不值钱
rdbcompression yes# RDB文件名称
dbfilename dump.rdb  # RDB文件保存的路径目录   ./表示当前目录
dir ./

RDB的缺点

如果发生断电，则RDB会存在丢失数据的风险：上一次触发了RDB，下一次还没来得及触发突然发生断电了，两次RDB之间写入数据就有丢失的风险；
RDB它是将内存当中的数据以及快照直接保存在磁盘当中，写RDB文件比较耗时，耗费性能~！前提是你的内存当中存储的数据量比较大！

持久化机制 - AOF持久化

AOF全称为Append-Only File（追加文件）。
AOF备份文件：appendonly.aof
AOF持久化是将Redis服务器处理的每一个写命令/写操作(set命令 => 只记录影响数据变化的指令 => 增删改的)都会追加记录在AOF文件的末尾，以文本格式记录了Redis服务器收到的每个写操作的命令，可以看做是命令日志文件。
当Redis需要恢复数据时，只需重新执行AOF文件中的命令即可。
AOF持久化可以提供更高的数据安全性，因为在每次写操作后都会追加到AOF文件中，避免了数据丢失的风险。

AOF默认是关闭的，需要修改redis.windows.conf配置文件来开启AOF：

# 是否开启AOF持久化功能，默认是no,是关闭的,如果需要开启AOF持久化,则需要将no改为yes
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.windows.conf文件来配：

# 表示每执行一次写命令,立即记录到AOF文件(写一次,保存一次)
appendfsync always 
# sec是second-秒的简写,写命令执行完先放入AOF缓冲区,然后表示每隔1秒将缓冲区数据写到AOF文件,是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

AOF的三种同步策略对比：

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多，而且AOF会记录对同一个Key的多次写操作，但是只有最后一次写操作才有意义。
因此Redis给我们提供了一条命令，通过执行bgrewriteaof命令 => 对AOF日志进行重写，可以让AOF文件执行重写功能，AOF文件重写是Redis中一种优化AOF持久化机制的操作，它重新创建一个更小的AOF文件来替代原有的AOF文件，从而达到减轻磁盘空间占用和提高读取性能的目的，通过消除 / 删除已过期或已删除的数据的命令 => 只会记录该Key的最后一次修改，用最少的命令达到相同效果，从而在一定程度上去降低AOF日志文件的体积。
AOF文件重写的过程并不是简单的对原有的AOF文件进行压缩或者整理，而是通过读取内存中的数据来重建一个新的AOF文件，它会遍历Redis当前内存中的数据并将其以命令的形式写入到新的AOF文件中，整个过程不受原有AOF文件的影响，因此可以消除原AOF文件中已过期或已删除的数据。

AOF文件重写的触发方式有两种：

手动触发：通过发送bgwriteaof命令给Redis服务器，从而来手动触发AOF文件重写。
自动触发：通过设置redis.conf配置文件中的auto-aof-write-percentage和auto-write-min-size参数来配置自动触发AOF文件重写的条件。Redis也会在触发阈值时自动去重写AOF文件，当AOF文件的大小比上次文件增长超过指定的百分比，或者AOF文件的体积大小超过指定的最小体积时，Redis会自动触发AOF文件重写。

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

需要注意的是：AOF文件重写是一个耗时且消耗CPU资源的操作，可能会对Redis服务器产生负载，因此在生成环境中需要谨慎使用。

RDB和AOF对比

维度	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的写命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如aof	高，因为数据完整性更高
系统资源占用	高，大量cpu和内存消耗	低，主要是磁盘io资源，但aof重写时会占用大量cpu和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高常见