<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> BGSAVEbgsave（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 公布！