保证Redis内存中的数据不会丢失，Redis因为断电等意外停止运行。主要有两种持久化机制，分别是RDB和AOF。 ## RDB RDB持久化是把当前时刻的数据生成快照持久化到硬盘的过程。 ### **触发机制** 触发机制有手动和自动。 #### **手动触发** > 自动触发支持两个命令，save（已废弃），bgsave * save 执行时会阻塞Redis进程，如果当前进程数据过大，会阻塞过长的时间，不适合线上环境 * bgsave 作为save的优化方案，减少了阻塞时间。Redis进程fork子进程，并由子进程完成持久化过程。fork子进程期间会阻塞Redis进程。 #### **自动触发** ### 流程说明 bgsave是主流的触发RDB持久化方式  ### RDB的优缺点 #### 优点 1. RDB文件是某个时间点的全量数据，适合备份场景。比如每6小时执行bgsave命令，并把RDB文件拷贝到远程机器，用于灾难恢复。 2. 通过RDB文件恢复数据的速度远远快于AOF #### 缺点 1. 无法实时持久化（秒级别），fork的花费时间过长 2. 不同版本的Redis生成的RDB二进制文件格式不一致，无法全面兼容 ## AOF 1. 解决了RDB无法实时持久化的问题。（不需要fork子进程） 2. Redis持久化的主流方案。 3. 所有的写命令被保存到独立日志文件中，需要恢复数据时，执行该独立日志文件。 ### AOF工作流程  ### 缓存区同步文件策略 写命令被添加到AOF缓冲区之后，支持配置多种机制将缓冲区的内容写入日志文件。 1. 同步。写入缓冲区同步写入磁盘的AOF日志文件（系统fsync） 2. 异步1 ，【everysec】。日志写入缓冲区，调用系统write之后立即返回，fsync同步文件由另外的线程完成（write操作只写入磁盘缓冲区，Linux在内核提供了页缓冲区来提高） 3. 异步3【no】【默认策略】 。 与第二种的区别在于，fsync同步文件的策略，同步过程都由独立的线程完成，2每秒一次，3最长30秒。 ### 重写机制 随着AOF日志文件的越来越大，Redis引入了AOF重写机制压缩文件体积。 AOF文件重写是将当前数据转换为写命令重新写入到AOF文件。 触发机制分为手动和自动 1. 手动 调用**bgrewriteaof**命令 2. 自动 配置策略