目录

1、RDB（快照）

1.1、触发机制

1.2、RDB执行流程

1.3、优点

1.4、缺点：

2、AOF（只追加文件）

3、AOF重写

3.1、重写流程

3.2、AOF重写触发时机

4、Redis4.0混合持久化

4.1、混合持久化流程

4.2、优点

        Redis的持久化机制，目的在于故障恢复、灾难恢复、数据恢复。在redis宕机后，迅速使redis变得可用，并恢复宕机前的数据。

1、RDB（快照）

        某个时间点的全量数据备份。Redis默认的持久化机制。对redis中的数据执行周期性的持久化操作。比如每隔几分钟/几小时/几天，会生成当前时刻redis内存中数据的一份完整快照。

1.1、触发机制

save命令触发，bgsave命令触发，自动化触发。

• save命令：会阻塞当前Redis服务器，命令执行期间，Redis不能处理其他命令，线上环境禁用。
• bgsave命令：Redis主进程会fork一个子进程来完成RDB的过程，完成RDB后自动结束子进程，阻塞时间极短。
• 自动化触发：

        可以在redis.conf配置文件中进行配置：
        Save 900 10 每隔900秒，在这900秒时间内，如果有>=10个键发生变化，则生成当前时刻的快照文件。

1.2、RDB执行流程

1. Redis主进程检查是否有正在执行的RDB/AOF持久化任务，如果有，直接返回。
2. Redis主进程fork一个子进程来执行执行RDB操作。fork操作会短暂阻塞主进程(Redis读写)，fork操作完成后会发消息给主进程，恢复Redis读写。
3. RDB子进程根据Redis主进程的内存生成临时的快照文件，持久化完成后会使用临时快照文件替换掉原来的RDB文件。（该过程中主进程的读写不受影响，但Redis的写操作不会同步到主进程的主内存中，而是会写到一个临时的内存区域作为一个副本）
4. 子进程完成RDB持久化后会发消息给主进程，通知RDB持久化完成（将上阶段内存副本中的增量写数据同步到主内存）

1.3、优点

• 基于RDB文件来重启和恢复redis数据，效率高；
• RDB操作对redis主进程的影响非常小，因为redis只需要fork一个子进程，让子进程来进行RDB的持久化操作，使redis主进程保持高性能

1.4、缺点：

• 相较于AOF，RDB在进行灾难恢复时可能会丢失更多的数据。一般情况下，RDB每隔5分钟生成一次快照文件，那么宕机时，就可能会丢失5分钟的redis数据。
• Redis在通过RDB文件恢复数据时，如果文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。

2、AOF（只追加文件）

        持续增量备份。将每条写命令作为日志，以append-only的方式写入一个日志文件，在redis重启时，通过重新执行日志中的写入指令来重构整个Redis数据。

AOF的3中持久化方式为：

• appendfsync always：同步持久化，每次有数据修改发生时都写入AOF文件，性能低但数据完整。
• appendfsync everysec(推荐)：异步操作，每秒钟同步一次，最多会丢失1秒的数据
• appendfsync no: 永不直接调用文件同步，而是让操作系统来决定何时同步磁盘。性能较好，但很不安全。

优点：

• 灾难恢复时，数据丢失较少。Redis一般每秒进行一次写命令同步，最多就会丢失1秒的数据。
• Append-only模式写入，写入性能高，不会重新生成文件，没有磁盘寻址的开销。
• AOF日志文件过大的时候，会出现后台重写操作，对其中的指令进行压缩，创建出一份能够恢复数据的最小日志，也不会影响客户端的读写。

缺点：

• 相同数量的数据集，AOF文件通常要大于RDB。恢复速度慢。
• AOF基于写命令的数据恢复，相较于RDB快照文件恢复，更加脆弱，容易出bug。

3、AOF重写

3.1、重写流程

1. 当AOF日志文件达到一定大小时，会进行AOF重写。Redis主线程会创建一个子进程生成新的AOF文件，该文件只保留可以恢复数据的最小指令集。
2. 首先，redis会维护一个重写缓冲区，用于在子进程创建新的AOF文件期间，记录服务器执行的所有写命令。
3. 然后，子进程会读取Redis中的键值对，生成一份能恢复数据的最小日志文件。
4. 新的AOF文件生成后，redis主进程会将重写缓冲区中新增的写命令追加到新的AOF日志文件中，然后完成新旧AOF文件的替换。

5. 3.2、AOF重写触发时机

   1.         Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

        AOF重写过程中，不需要对原有AOF文件进行任何的读取、写入、分析等操作。

4、Redis4.0混合持久化

        Redis4.0新增混合持久化，将 rdb 文件的内容和增量的 AOF 日志文件存在一起。 

        混合持久化默认关闭，可通过配置aof‐use‐rdb‐preamble yes开启       

        将RDB和AOF混合使用，例如恢复的时候先根据照片恢复最后一次拍照记录的样子，然后再恢复拍照后记录的动作。

• RDB方式恢复数据：快照时间粒度大，易丢失大量数据。
• AOF方式恢复数据：性能较RDB要低，Redis数据量大的情况下，启动花费时间长。

4.1、混合持久化流程

1. 在AOF重写时，会将重写这一刻之前的内存做RDB快照处理；
2. 然后将RDB快照内容和增量的AOF修改内存数据的命令存在一起，写入新的AOF文件；
3. 重写完后，覆盖原有的AOF文件，完成AOF重写。

        在Redis重启的时候，可以先加载RDB的内容，然后再执行增量AOF日志就可以完全替代之前的AOF全量文件执行，重启效率大幅得到提升。

4.2、优点

• 大量数据使用RDB快照方式，性能高，恢复时间快。
• 增量数据使用AOF日志方式，尽量保证数据不丢失。

以上内容为个人学习理解，如有问题，欢迎在评论区指出。

部分内容截取自网络，如有侵权，联系作者删除。

最后

以上就是着急煎蛋为你收集整理的Redis持久化机制1、RDB（快照）2、AOF（只追加文件）3、AOF重写4、Redis4.0混合持久化的全部内容，希望文章能够帮你解决Redis持久化机制1、RDB（快照）2、AOF（只追加文件）3、AOF重写4、Redis4.0混合持久化所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。