Redis持久化
RDB持久化
AOF持久化
混合持久化
RDB
介绍
介绍：全称Redis Database file（Redis数据备份文件），又称Redis数据快照。
简单说就是把内存种的所有数据都记录到磁盘中，当Redis实例出故障重启后，从磁盘读取快照文件，恢复数据。
快照文件称 RDB文件，默认保存在当前运行目录。
save #由Redis主进程来执行RDB，会阻塞其他命令 bgsave #开启子进程执行RDB，避免主线程受到影响
如果主动停机，会执行一次RDB。
配置
Redis内部有触发RDB机制，可在redis.conf文件中找到，格式如下：
#900s内，如果至少有一个key被修改，则执行bgsave，如果是save ""，则表示禁用RDB
save 900 1
save 300 10
save 60 10000RDB的其他配置也可在redis.conf中配置：
#是否压缩，建议不开启，压缩会消耗cpu，磁盘不如cpu值钱
rdbcompression yes
#RDB文件名称
dbfilename dump. rdb
#文件保存的路径目录
dir ./bgsave底层实现
bgsave开始时会fork（复制）主进程得到子进程，子进程共享进程的内存数据。
完成fork后读取内存数据并写入RDB文件。
fork采用的是cope-on-write计数：
当主进程执行读操作时，访问共享内存。
当主进程执行写操作时，会拷贝一份数据，执行写操作。
总结
RDB方式bgsave的基本流程：
fork主进程得到一个子进程，共享内存空间
子进程读取内存数据并写入新的RDB文件
用新RDB文件替换旧的RDB文件
RDB会在什么时候执行？
默认是服务停止时。
save 60 100 代表什么含义？
代表60秒内至少执行1000次修改触发RDB
RDB的缺点？
RDB执行间隔时间长，两次RDB之间写入数据有丢失风险
fork子进程、压缩、写出RDB文件都比较耗时。
AOF持久化
介绍
AOF全称Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看作命令日志文件。
配置
AOF默认关闭，需要修改redis.conf配置文件来开启AOF：
#是否开启AOF功能，默认是no
appendonly yes
#AOF文件的名称
appendfilename "appendonly.aof"AOF的命令记录的频率可以通过redis.conf文件来配置：
#表示每执行一次写命令，立即记录到AOF文件
appendfsync always
#写命令执行完后先放AOF缓冲区，然后表示每隔一秒将缓冲区数据写到AOF文件（默认方案）
appendfsync everysec
#写命令执行完后放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no| 配置项 | 刷盘时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步刷盘 | 可靠性高，几乎不丢失数据 | 性能影响大 |
| everysec | 每秒刷盘 | 性能适中 | 最多丢失1秒数据 |
| no | 操作系统控制 | 性能适中 | 可靠性较差，可能丢失大量数据 |
由于AOF是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只要最后一次有意义。
可以通过 bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到同样的效果。
Redis也会在触发阙值时自动去重写AOF文件。阙值在redis.conf文件中配置：
#AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
#AOF文件体积最小多大才触发重写
auto-aof-rewrite-min-size 64mbRDB和AOF对比
如果对数据安全性要求高的，在实际开发中往往会结合两种来使用。
| RDB | AOF | |
|---|---|---|
| 持久化方式 | 定时对整个内存做快照 | 记录每次执行的命令（类似日志） |
| 数据完整性 | 不完整，两次备份之间会丢失 | 相对完整，取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积很大 |
| 宕机恢复速度 | 很快（直接使用快照） | 慢（AOF文件体积大） |
| 数据恢复优先级 | 低，因为数据完整性不如AOF | 高，因为数据完整性更高 |
| 系统资源占用 | 高，大量CPU和内存消耗 | 低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失，追求更快的启动速度 | 对数据安全性要求较高 |
混合持久化
RDB 优点是数据恢复速度快，但是快照的频率不好把握。频率太低，丢失的数据就会比较多，频率太高，就会影响性能。
AOF 优点是丢失数据少，但是数据恢复不快。
为了集成了两者的优点， Redis 4.0 提出了混合使用 AOF 日志和内存快照，也叫混合持久化，既保证了 Redis 重启速度，又降低数据丢失风险。
Redis 4.0 引入的混合持久化并不是将 RDB 和 AOF 直接混合在一起，而是通过将 RDB 和 AOF 持久化结合起来，利用它们各自的优势来提高数据持久化的可靠性和性能。
具体来说，混合持久化是指在 Redis 4.0 中可以同时启用 RDB 快照和 AOF 日志，而不是替代其中一个。在混合持久化模式下，Redis 会使用 RDB 快照来实现周期性的全量备份，同时使用 AOF 日志来记录每个写操作的指令，以确保数据的实时持久化和恢复。
在写操作的时候，Redis 会先将写操作记录到 AOF 日志中，然后根据配置的条件进行 AOF 日志的刷盘（fsync），以确保写操作的持久化。同时，Redis 也会在配置的条件下周期性地执行 RDB 快照，以创建全量备份。因此，在混合持久化模式下，写操作既会触发 AOF 日志的追加，也可能触发 RDB 快照的生成。
优点：
- 混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。
缺点：
- AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
- 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了
