关于java:一文让你明白Redis持久化RDBAOF

<img src=”http://www.image.jincou.com/33974b8cb6fd49ffb46b217019c0435b” width=“700”height=“300”>

为什么要长久化

Redis 是内存数据库，如果不将内存中的数据库状态保留到磁盘中，那么一旦服务器过程退出，服务器的数据库状态就会隐没(即断电即失)。为了保证数据不失落，咱们须要将内存中的数据存储到磁盘，以便 Redis 重启时可能从磁盘中复原原有的数据，而整个过程就叫做 Redis 长久化。

Redis 长久化也是 Redis 和 Memcached 的次要区别之一，因为 Memcached 是不具备长久化性能的。

长久化的几种形式

Redis 长久化领有以下三种形式：

快照形式（RDB, Redis DataBase）将某一个时刻的内存数据，以二进制的形式写入磁盘；

文件追加形式（AOF, Append Only File），记录所有的写操作命令，并以文本的模式追加到文件中；

混合长久化形式，Redis 4.0 之后新增的形式，混合长久化是联合了 RDB 和 AOF 的长处，在写入的时候，先把以后的数据以 RDB 的模式写入文件的结尾，再将后续的操作命令以 AOF 的格局存入文件，这样既能保障 Redis 重启时的速度，又能防止数据失落的危险。

因为每种长久化计划，都有特定的应用场景，让咱们先从 RDB 长久化说起吧。

一、什么是 RDB，RDB 如何实现长久化？

1、什么是 RDB？

RDB 是 Redis Database 的缩写，其作用是在 某一个工夫点，将 Redis 存储在内存中的数据生成快照并存储到磁盘等介质上，存在这个磁盘介质上的文件就是 RDB 文件。“快照”顾名思义就是如同照相一样保留过后的数据，这里 RDB 文件是一个二进制的文件，并且是通过压缩的。因为 RDB 文件是保留在硬盘中的，即便 Redis 服务器过程退出，甚至运行 Redis 服务器的计算机宕机，但只有 RDB 文件依然存在，Redis 服务器就能够用它来还原数据库状态。

2、触发形式(手动、主动)

RDB 的长久化触发形式有两类：一类是手动触发，另一类是主动触发。

1）手动触发（执行 save 或者 bgsave 命令）

手动触发长久化的操作有两个命令：save 和 bgsave，它们次要区别体现在：是否阻塞 Redis 主线程的执行。

save 命令

redis 127.0.0.1:6379> SAVE

在客户端中执行 save 命令，就会触发 Redis 的长久化，但同时也是使 Redis 处于阻塞状态，直到 RDB 长久化实现，才会响应其余客户端发来的命令，所以在生产环境肯定要慎用。

<img src=”http://www.image.jincou.com/b998609afe7847949cfda558454c7241″ width=“775”height=“300”>

bgsave 命令

redis 127.0.0.1:6379> BGSAVE

bgsave（background save）既后盾保留的意思，它和 save 命令最大的区别就是 bgsave 会 fork() 一个子过程来执行长久化，整个过程中只有在 fork() 子过程时有短暂的阻塞，当子过程被创立之后，Redis 的主过程就能够响应其余客户端的申请了，绝对于整个流程都阻塞的 save 命令来说，显然 bgsave 命令更适宜咱们应用。

<img src=”http://www.image.jincou.com/14026ee477474a8ba061b9ad6c0b069e” width=“775”height=“300”>

在快照进行的过程中，也就是生成文件的过程中，不会对原有的 RDB 文件进行批改，直到快照生成结束，间接将老的替换成新的，保障 rdb 文件任何时刻都是残缺的。

2) 主动触发

主动触发的含意就是不必咱们手动命令去触发长久化，而是通过配置当满足某一规定的时候主动去执行 bgsave 命令。

Redis 的配置文件就默认设置了 3 个保留点：

# 以下配置示意的条件：# 900 秒内有 1 个 key 产生了变动，则触发保留 RDB 文件
save 900 1
# 服务器在 300 秒之内被批改了 10 次
save 300 10
# 服务器在 60 秒之内被批改了 10000 次
save 60 10000

#如果想禁用快照保留的性能，能够通过正文掉所有 "save" 配置达到，或者在最初一条 "save" 配置后增加如下的配置：save ""

留神这里满足条件执行的是 bgsave 命令。

二、什么是 AOF，AOF 如何实现长久化？

1、什么是 AOF？

以日志的模式来记录 每个写操作，将 Redis 执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不能够改写文件，redis 启动之初会读取该文件从新构建数据，换言之，redis 重启的话就依据日志文件的内容将写指令从前到后执行一次以实现数据的复原工作。

默认状况下，redis 是没有开启 AOF(append only file)的。开启 AOF 性能须要设置配置：appendonly yes。

2、AOF 长久化流程

下面提到了 AOF 长久化的过程就是日志一直追加的过程，这里通过图 给大家介绍具体流程：

<img src=”http://www.image.jincou.com/a4affd2236ff4d1e9dc3dfd892450f44″ width=“775”height=“300”>

1、Client 作为命令的起源，会有多个源头以及源源不断的申请命令。

2、在这些命令达到 Redis Server 当前，并不是间接写入 AOF 文件，会将其这些命令先放入 AOF 缓存 中进行保留。这里的 AOF 缓冲区实际上是内存中的一片区域，存在的目标是当这些命令达到一定量当前再写入磁盘，防止频繁的磁盘 IO 操作。

3、AOF 缓冲会依据对应的 策略 将命令写入磁盘上的 AOF 文件。

4、AOF 文件随着写入文件内容的减少，会依据规定进行命令的合并，这里叫做AOF 重写，从而起到 AOF 文件压缩的目标。

5、当 Redis Server 服务器重启的时候会从 AOF 文件载入数据。

这外面有两点须要在具体写: AOF 缓冲区同步文件策略 和 AOF 重写机制。

3、AOF 缓冲区同步文件策略

下面提到了 Redis 会将命令先写入到 AOF 缓冲区，再写入 AOF 文件。这里介绍一下 AOF 缓冲区同步文件的三个策略。

#aof 长久化策略的配置
appendfsync always    #always 示意每次写入都执行 fsync，以保证数据同步到磁盘
appendfsync everysec   #everysec 示意每秒执行一次 fsync，可能会导致失落这 1s 数据
appendfsync no   #no 示意不执行 fsync，由操作系统保证数据同步到磁盘，速度最快

Always 策略的同步操作是在主过程的主线程中进行的，因为 fsync 的阻塞个性，会导致其挂起，在此期间无奈服务新的申请，因此吞吐量降落，但的确可能保障内存和硬盘中数据的一致性。

Everysec 策略的同步操作是通过后盾 I / O 线程进行的，因为是在子线程中进行，所以主线程并不会被阻塞，能够持续服务新的申请，然而内存和硬盘中的数据会有 1 秒的差异（不肯定精准），这是一种折衷的计划，寻求了一个均衡。

No 策略则是将同步操作的控制权交由操作系统，不阻塞主线程，然而数据一致性可能会偏差很大

官网倡议应用默认配置每秒同步，它既疾速又平安。这个 always 策略在实践中十分迟缓，没有方法做得 fsync 比当初更快。

4、AOF 重写机制

（1）是什么？

AOF 采纳文件追加形式，文件会越来越大为避免出现此种状况，新增了重写机制, 当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留能够复原数据的最小指令集。

举个例子：比方有个 key 一开始你 set key 1，而后改成 set key 2，最初 set key 3。如果不重写那么这 3 条语句都在文件中，这样即占空间，启动的时候都要执行一遍有效的命令，如果重写后，只须要保留 set key 3 就能够了。

AOF 重写不仅升高了文件的占用空间，同时更小的 AOF 也能够更快地被 Redis 加载。

（2）触发机制(手动、主动）

手动：客户端向服务器发送 bgrewriteaof 命令

主动：满足配置文件中的选项后，主动执行 bgrewriteaof 命令。Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。

（3）重写原理

AOF 文件持续增长而过大时，会 fork 出一条新过程来将文件重写(也是先写临时文件最初再 rename)，遍历新过程的内存中数据，每条记录有一条的 Set 语句。重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的形式重写了一个新的 aof 文件，这点和快照有点相似。

三、RDB 和 AOF 各自优缺点

1、RDB 的长处

（1）比起 AOF，在数据量比拟大的状况下，RDB 的启动速度更快。

（2）RDB 文件是一个很简洁的单文件，它保留了某个工夫点的 Redis 数据，很适宜用于做备份。

（3）RDB 的性能很好，须要进行长久化时，主过程会 fork 一个子过程进去，而后把长久化的工作交给子过程，本人不会有相干的 I / O 操作。

2、RDB 毛病

（1）RDB 容易造成数据的失落。假如每 5 分钟保留一次快照，如果 Redis 因为某些起因不能失常工作，那么从上次产生快照到 Redis 呈现问题这段时间的数据就会失落了。

（2）RDB 应用 fork()产生子过程的过程会梗塞主过程，所以数据比拟大的话 fork() 可能很耗时，就会造成 Redis 进行服务几毫秒。

3、AOF 长处

（1）该机制能够带来更高的数据安全性，即数据持久性。Redis 中提供了 3 中同步策略，即每秒同步、每批改同步和不同步。事实上，每秒同步也是异步实现的，其效率也是十分高的，如果产生劫难，您只可能会失落 1 秒的数据。

（2）AOF 日志文件是一个纯追加的文件。就算服务器忽然 Crash，也不会呈现日志的定位或者损坏问题。甚至如果因为某些起因（例如磁盘满了）命令只写了一半到日志文件里，咱们也能够用 redis-check-aof 这个工具很简略的进行修复。

（3）当 AOF 文件太大时，Redis 会主动在后盾进行重写。重写很平安，因为重写是在一个新的文件上进行。

4、AOF 毛病

（1）在雷同的数据集下，AOF 文件的大小个别会比 RDB 文件大。

（2）AOF 开启后，写 QPS 会比 RDB 的低。通常 fsync 设置为每秒一次就能取得比拟高的性能，而在禁止 fsync 的状况下速度能够达到 RDB 的程度。

四、生产配置长久化的一些意见

（1）官网倡议：是同时开启两种长久化策略。因为有时须要 RDB 快照是进行数据库备份，更快重启以及产生 AOF 引擎谬误的解决办法。（换句话就是通过 RDB 来多备份一份数据总是好的）

（2）因为 RDB 文件只用作后备用处，倡议只在 Slave 上长久化 RDB 文件，而且只有 15 分钟备份一次就够了，只保留 save 900 1 这条规定。

（3）如果抉择 AOF，只有硬盘许可，应该尽量减少 AOF rewrite 的频率。因为一是带来了继续的 IO，二是 AOF rewrite 的最初将 rewrite 过程中产生的新数据写到新文件造成的阻塞简直是不可避免的。
AOF 重写的根底大小默认值 64M 太小了，能够设到 2G 以上。

本文由博客一文多发平台 OpenWrite 公布！