redis的持久化（2）

1.背景

 众所周知 redis是一个内存数据库，所以他的运行效率特别高。但是也存在一个问题：因为内存中的数据不是持久的，所以当redis宕机或者关机重启，那内存中的数据就全部丢失了。

  当然这肯定是不允许的，redis是具有持久化机制的，它会通过设置  以快照或者操作日志的形式将数据持久化到磁盘中。

  根据持久化使用技术的不同，Redis 的持久化分为两种：RDB 与 AOF。

  Redis 持久化也称为钝化，是指将内存中数据库的状态描述信息保存到磁盘中。只不过是不同的持久化技术，对数据的状态描述信息是不同的，生成的持久化文件也是不同的。但它们的作用都是相同的：避免数据意外丢失。通过手动方式，或自动定时方式，或自动条件触发方式，将内存中数据库的状态描述信息写入到指定的持久化文件中。当系统重新启动时，自动加载持久化文件，并根据文件中数据库状态描述信息将数据恢复到内存中，这个数据恢复过程也称为激活。这个钝化与激活的过程就是 Redis 持久化的基本原理。 

  不过从以上分析可知，对于 Redis 单机状态下，无论是手动方式，还是定时方式或条件触发方式，都存在数据丢失问题：在尚未手动/自动保存时发生了 Redis 宕机状况，那么从上次保存到宕机期间产生的数据就会丢失。不同的持久化方式，其数据的丢失率也是不同的。

  需要注意的是，RDB 是默认持久化方式，但 Redis 允许 RDB 与 AOF 两种持久化技术同时开启，此时系统会使用 AOF 方式做持久化，即 AOF 持久化技术的优先级要更高。同样的道理，两种技术同时开启状态下，系统启动时若两种持久化文件同时存在，则优先加载 AOF持久化文件。

2.RDB

中间请看上文   ↓↓↓↓↓↓↓↓

redis的持久化（1）

3.AOF

AOF，Append Only File，是指 Redis 将每一次的写操作都以日志的形式记录到一个 AOF文件中的持久化技术。当需要恢复内存数据时，将这些写操作重新执行一次，便会恢复到之前的内存数据状态。

还是打开redis.config 找到 APPEND ONLY MODE 这个下面就是aof的一些配置项

appendonly no

默认情况下 AOF 持久化是没有开启的，通过修改配置文件中的 appendonly 属性为 yes可以开启。

Redis 7 在这里发生了重大变化。原来只有一个 appendonly.aof 文件，现在具有了三类多个文件：

基本文件：可以是 RDB 格式也可以是 AOF 格式。其存放的内容是由 RDB 转为 AOF 当时内存的快照数据。该文件可以有多个。
增量文件：以操作日志形式记录转为 AOF 后的写入操作。该文件可以有多个。
清单文件：用于维护 AOF 文件的创建顺序，保障激活时的应用顺序。该文件只有一个。

这里版本是 Redis-x64-5.0.14.1 

appendfsync 

参数有三个选项：

always：每处理一个命令都将 aof_buf 缓冲区中的所有内容写入并同步到AOF 文件，即每个命令都刷盘

everysec：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，如果上次同步 AOF 文件的时间距离现在超过一秒钟， 那么再次对 AOF 文件进行同步， 并且这个同步操作是异步的，由一个后台线程专门负责执行，即每秒刷盘1次。

no：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 但并不对 AOF 文件进行同步， 何时同步由操作系统来决定。即不执行刷盘，让操作系统自己执行刷盘。

aof-use-rdb-preamble 

持久化混合开启

 

对于基本文件可以是 RDF 格式也可以是 AOF 格式。通过 aof-use-rdb-preamble 属性可以选择。其默认值为 yes，即默认 AOF 持久化的基本文件为 rdb 格式文件，也就是默认采用混合式持久化。

• (+) 表示一个正确的状态信息
• (-) 表示一个错误信息
• (*) 表示消息体总共有多少行，不包括当前行
• ($) 表示下一行消息数据的长度，不包括换行符长度\r\n
• (空) 表示一个消息数据

*3 --表示当前命令包含 3 个参数

$3 -- 表示第 1 个参数包含 3 个字符

set -- 第 1 个参数

$3 -- 表示第 2 个参数包含 3 个字符

k11 -- 第 2 个参数

$3 -- 表示第 3 个参数包含 3 个字符

v11 -- 第 3 个参数

该文件首先会按照 seq 序号列举出所有基本文件，基本文件 type 类型为 b，然后再按照seq 序号再列举出所有增量文件，增量文件 type 类型为 i。

对于 Redis 启动时的数据恢复，也会按照该文件由上到下依次加载它们中的数据。

Rewrite 机制

所谓 Rewrite 其实就是对 AOF 文件进行重写整理。当 Rewrite 开启后，主进程 redis-server创建出一个子进程 bgrewriteaof，由该子进程完成 rewrite 过程。其首先对现有 aof 文件进行rewrite 计算，将计算结果写入到一个临时文件，写入完毕后，再 rename 该临时文件为原 aof文件名，覆盖原有文件。

• 读操作命令不写入文件
• 无效命令不写入文件
• 过期数据不写入文件
• 多条命令合并写入文件

 

AOF 详细的持久化过程如下：

Redis 接收到的写操作命令并不是直接追加到磁盘的 AOF 文件的，而是将每一条写命令按照 redis 通讯协议格式暂时添加到 AOF 缓冲区 aof_buf。

根据设置的数据同步策略，当同步条件满足时，再将缓冲区中的数据一次性写入磁盘的AOF 文件，以减少磁盘 IO 次数，提高性能。

当磁盘的 AOF 文件大小达到了 rewrite 条件时，redis-server 主进程会 fork 出一个子进程bgrewriteaof，由该子进程完成 rewrite 过程。

子进程 bgrewriteaof 首先对该磁盘 AOF 文件进行 rewrite 计算，将计算结果写入到一个临时文件，全部写入完毕后，再 rename 该临时文件为磁盘文件的原名称，覆盖原文件。

如果在 rewrite 过程中又有写操作命令追加，那么这些数据会暂时写入 aof_rewrite_buf缓冲区。等将全部 rewrite 计算结果写入临时文件后，会先将 aof_rewrite_buf 缓冲区中的数据写入临时文件，然后再 rename 为磁盘文件的原名称，覆盖原文件。

4.对比

RDB 与 AOF 对比
RDB 优势与不足
RDB 优势
RDB 文件较小

数据恢复较快

RDB 不足
数据安全性较差

写时复制会降低性能

RDB 文件可读性较差

AOF 优势与不足
AOF 优势
数据安全性高

AOF 文件可读性强

AOF 不足
AOF 文件较大

写操作会影响性能

数据恢复较慢

混合持久化并不是一种全新的持久化方式，而是对已有方式的优化。混合持久化只发生于 AOF 重写过程。使用了混合持久化，重写后的新 AOF 文件前半段是 RDB 格式的全量数据，后半段是 AOF 格式的增量数据。

好了 AOF 就分享到这里 

如果对AFO有更好了解  欢迎大家评论！