长久化

长久化（Persistence），即把内存中的数据保留到磁盘中。

长久化的实现形式

快照式

在某个时刻把所有数据进行残缺备份。

例：MySQL 的 Dump 形式、Redis 的 RDB 形式。

日志式

把用户执行的所有写指令（增删改）备份到文件中，还原数据时只须要把备份的所有指令从新执行一遍即可。

例：MySQL 的 Binlog、Redis 的 AOF、Hbase 的 HLog。

AOF 简介

在文章《Redis长久化 - RDB》中提到过，应用 RDB 做长久化，如果 Redis 意外宕机（例如电源中断），可能会失落上一次备份到宕机前这段时间的数据。

为了防止上述问题，能够应用另一种长久化实现形式：AOF 长久化。

配置 AOF 长久化之后，每当 Redis 执行一个扭转数据集的命令， 这个命令就会被追加到 AOF 文件的开端。当 Redis 从新启时，程序就能够通过从新执行 AOF 文件中的命令来达到重建数据集的目标。

AOF长久化的三种策略

always

每次有新命令执行就刷新缓冲区，将命令追加到 AOF 文件，速度绝对其余策略慢、IO开销大，然而安全性十分高。

everysec（默认&举荐）

每秒刷新一次缓冲区，将命令追加到 AOF 文件，速度足够快并且在故障时只会失落 1 秒钟的数据。

no

不刷新缓冲区内容，由操作系统来决定什么时候同步数据。最快但也最不平安。

AOF 重写

因为 AOF 的运作形式是一直地将命令追加到文件的开端， 所以随着写入命令的一直减少， AOF 文件的体积也会变得越来越大。然而很多命令的执行实际上会笼罩原有命令的后果（如自增 INCR），导致保留原有命令是多余的。

为此，Redis 能够在不打断服务客户端的状况下， 对 AOF 文件进行重建（rebuild）。手动执行 bgrewriteaof 命令， Redis 将生成一个新的 AOF 文件， 这个文件蕴含重建以后数据集所需的起码命令。

bgrewriteaof 命令是异步执行的，即便 bgrewriteaof 执行失败，也不会有任何数据失落，因为旧的AOF文件在 bgrewriteaof 胜利之前不会被批改。

Redis 2.4 开始能够通过配置主动触发 AOF 重写。

AOF重写的作用

  • 能够缩小磁盘占用量
  • 能够更快地数据恢复

AOF 配置

# 开启AOF长久化appendonly yes# AOF长久化文件名appendfilename appendonly-<port>.aof# 每秒把缓冲区的数据同步到磁盘appendfsync everysec# 数据长久化文件存储目录dir /var/lib/redis# 是否在执行重写时不同步数据到AOF文件# 这里的 yes，就是执行重写时不同步数据到AOF文件no-appendfsync-on-rewrite yes# 触发AOF文件执行重写的最小尺寸auto-aof-rewrite-min-size 64mb# 触发AOF文件执行重写的文件体积增长率auto-aof-rewrite-percentage 100

主动触发AOF重写，须要同时满足上面两个条件：

  • aof_current_size > auto-aof-rewrite-min-size
  • (aof_current_size - aof_base_size) * 100 / aof_base_size > auto-aof-rewrite-percentage
aof_current_size：AOF文件以后尺寸（字节）
aof_base_size：AOF文件上次启动和重写时的尺寸（字节）

AOF 重写流程

AOF的长处

  1. 依据不同的fsync策略，能够兼顾性能和数据安全性。
  2. AOF 文件是一个只进行追加的日志文件，即便因为某些起因(磁盘空间已满，写的过程中宕机等)未执行残缺的写入命令，也能够应用 redis-check-aof 工具修复这些问题。
  3. Redis 能够在 AOF 文件体积变得过大时，主动地在后盾执行 AOF 重写，重写后的新 AOF 文件蕴含了复原以后数据集所需的最小命令汇合。Redis 在创立新 AOF 文件的过程中，会持续将命令追加到原有的 AOF 文件外面，即便重写过程中产生宕机，原有的 AOF 文件也不会失落。一旦新 AOF 文件创建结束，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
  4. AOF 文件有序地保留了对数据库执行的所有写操作，这些写操作以 Redis 命令的格局保留， 因而能够很轻松地对 AOF 文件的内容进行剖析。 例如，如果不小心执行了 FLUSHALL 命令，只有 AOF 文件未被重写，那么只有进行服务器，移除 AOF 文件开端的 FLUSHALL 命令，并重启 Redis ，就能够将数据集复原到 FLUSHALL 执行之前的状态。

AOF的毛病

  1. 对雷同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
  2. 依据不同的 fsync 策略，AOF 的速度可能会慢于 RDB 。