redis持久化

为什么需要持久化

Redis为内存数据库， 所有的数据都保存在内存中，为了避免意外或者机器发生故障的情况，造成数据的丢失，所以要做持久化操作。持久化的意义，主要是为了数据重用。当redis重启或者机器重启时，将原先存在的数据在恢复到redis中，来提供数据服务。

redis持久化机制

Redis提供了两种持久化方案,分别为：

• 快照RDB（snapshotting）: 将当前数据保存到硬盘
• 只追加文件AOP（append-only file）：将每次写入的命令保存到硬盘

RDB持久化

RDB持久化是将redis中某个时间点上存储数据的全部拷贝，形成一个数据的副本，保存的文件后缀为rdb。 此文件 dump.rdb(默认文件名) 保存了当前redis中的全部数据， 可以对此文件进行备份操作，如：复制到另外的主机，或者云主机等。生成快照文件后，redis在重新启动时，会自动的加载快照中的数据。

触发条件

RDB持久化的触发分为下面几种：

• 客户端发送save和bgsave命令：但是save和bgsave命令虽然都可以完成快照的创建，但是它们还是有一点区别。save命令会阻塞当前redis服务，在快照完成创建之前不再响应其他任何的命令。而bgsave，会调用fork来创建一个子进程，在子进程创建成功之前，会阻塞redis服务，创建成功后，由这个子进程来完成创建快照的操作，父进程继续接受redis命令，来提供服务。

• 配置文件redis.conf中配置了 save m n 选项。 该选项的意思是 redis在 m长的时间内执行了n 次操作，就进行bgsave操作。 save m n 选项运行配置多条。例如save 900 1 表示 900秒内执行了1次操作就触发bgsave命令。

• redis服务器接受到shutdown指令，会执行一个save命令

• 当一个服务器连接到另外一个redis服务器，并向对方发送sync命令来开始一次复制操作时，可能会执行bgsave操作

RDB执行流程

RDB持久化机制的工作流程：

• redis根据配置自己尝试去生成rdb配置文件
• fork 一个子进程
• 子进程尝试将数据dump到临时的rdb快照文件中
• 完成rdb快照文件的创建工作后，将替换之前的快照文件 ， dump.rdb 每次生成一个新的快照，将会覆盖之前的老的快照

RDB优缺点

优点：

• RDB会生成多个数据文件，每个数据文件都代表了某一个时刻的全部数据，非常适合用来做冷备
• RDB对redis对外提供的读写服务影响非常小，因为fork了一个子进程来做快照的创建工作
• 相对于AOF持久化来说，基于RDB的数据恢复工作会更加的快速

缺点：

• 如果发生服务器崩溃，将丢失最近一次创建快照后，更改的所有数据
• 如果数量比较大，比如redis中已经存储了几十G的数据，可能会导致redis服务暂停数豪秒甚至几秒。redis进程每占用一个G内存，创建该子进程所需的时间就要增加10~20毫秒。

常用配置

下面是RDB常用的配置项，以及默认值：

• save m n： 触发bgsave保存快照文件
• stop-writes-on-bgsave-error yes：当bgsave出现错误时，Redis是否停止执行写命令；设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no
• rdbcompression yes：是否开启RDB文件压缩
• rdbchecksum yes：是否开启RDB文件的校验，在写入文件和读取文件时都起作用；关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现
• dbfilename dump.rdb：RDB文件名
• dir ./：RDB文件和AOF文件所在目录

AOF持久化

AOF持久化将会被执行的命令写到AOF文件的末尾，依次来记录数据发生的变化。因为在进行数据恢复的时候，只要把AOF文件从头到尾再执行一遍就可以恢复了。aof持久化默认是关闭的，需要将 appendonly no 选项改成 appendonly yes 来开启。AOF记录的是写入的命令，无须显示触发。

AOF工作流程

AOF的工作流程： 打开AOF持久化的配置选项后，redis每次接收一条写命令，都会写入日志文件中，具体的步骤是，先如写入系统的os cache 中，然后每隔一定的时间执行fsync操作，在保存到文件中。

关于fsync操作，redis的配置文件中提供了 appendfsync选项来支持不同的选择策略，可配置策略如下：

• always: 每个写命令都要同步到硬盘，降低了redis的速度
• everysec: redis的默认配置选项，每秒执行一次同步
• no: 让操作系统来决定应该何时进行同步。

重写和压缩AOF文件

如果开启了AOF选项，那么最低会丢失一秒的数据，而且也可以在极短的时间内完成定期的持久化操作，那么我们为什么不使用 AOF持久化呢？ 这个问题没有那么简单，如果我们不停的往aof文件写入命令，那么会造成aof的文件很大，比较恐怖的情况就是，aof文件用完了所有的硬盘空间。为了解决AOF文件不断增大的问题，所以redis引入了重写（rewrite）来解决，需要特别说明的是重写是对redis中的数据转化为写命令，不会对旧的AOF文件进行任何的读取和写入操作。

文件重写的触发

手动触发：发送 bgrewriteof命令
自动触发：配置 auto-aof-rewrite-min-size和auto-aof-rewrite-percentage选项。 假设用户对redis设置了auto-aof-rewrire-min-size 64M 和 auto-aof-rewrite-percentage 100 ,而且启用了aof , 那么当aof文件的体积大于64M，而且比上次重写之后的体积大了一倍的时候，redis就会触发bgrewriteaof操作。

AOF优缺点

优点：

• AOF可以更好的保护数据不丢失，即使丢失也是丢失一秒的数据
• AOF已append-only模式，无任何磁盘寻址开销，写入性能非常高
• 不会影响redis服务的读写
• 适合做灾难性的紧急恢复。例如，有人不小心删除了数据库中的所有数据，只要这个时候后台没有rewrite，删除aof文件中的最后一条命令就可以进行数据的恢复。

缺点：

• 对于同一份数据，AOF文件比RDB文件要大
• AOF开启之后，支持写的QPS会比RDB支持写的QPS低

AOF常用配置

下面是AOF常用的配置项，以及默认值：

• appendonly no：是否开启AOF
• appendfilename "appendonly.aof"：AOF文件名
• dir ./：RDB文件和AOF文件所在目录
• appendfsync everysec：fsync持久化策略
• no-appendfsync-on-rewrite no：AOF重写期间是否禁止fsync，如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据；需要在负载和安全性之间进行平衡
• auto-aof-rewrite-percentage 100：文件重写触发条件之一
• auto-aof-rewrite-min-size 64mb：文件重写触发提交之一
• aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件