Redis的持久化机制

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

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

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

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

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

持久化机制 - RDB持久化 RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照，是Redis默认的持久化方式。简单来说就是把/将Redis内存当中的所有数据以二进制形式都记录/保存到磁盘当中，当Redis实例发生故障重启后，此时会从磁盘读取快照文件并加载到内存当中，从而来恢复数据。Disk：磁盘   DB  loaded  from  diskRDB备份文件：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对比维度RDBAOF持久化方式定时对整个内存做快照记录每一次执行的写命令数据完整性不完整，两次备份之间会丢失相对完整，取决于刷盘策略文件大小会有压缩，文件体积小记录命令，文件体积很大宕机恢复速度很快慢数据恢复优先级低，因为数据完整性不如aof高，因为数据完整性更高系统资源占用高，大量cpu和内存消耗低，主要是磁盘io资源，但aof重写时会占用大量cpu和内存资源使用场景可以容忍数分钟的数据丢失，追求更快的启动速度对数据安全性要求较高常见

RDB和AOF各有自己的优缺点，可以选择同时启用RDB和AOF持久化，这样在Redis重启时可以使用RDB文件加载数据，通过重放AOF文件中的命令来实现数据的完整性和一致性~！