1. 为什么须要长久化？

Redis的读写和响应速度为什么如此之快？不同于传统的关系型数据库，Redis的数据库是全副加载在实时内存中的，读写操作可能间接在内存中进行，省去了大量IO操作，因而性能十分优越。但所有依靠于内存的服务都有个最大的软肋，那便是在设施呈现故障(如断点)时，内存中所有的实时数据都将会失落。为了解决这个问题，Redis中提供了两种长久化计划：RDB和AOF，其机制实际上都是设法将内存中的数据以文件的模式备份到磁盘上，从而解决断电等机器故障导致数据失落的问题。

2. RDB (Redis DataBase)

实现机制：Redis会独自创立(fork)一个子过程来进行长久化，会先将数据写入到一个临时文件中，待长久化过程完结后，再用这个临时文件替换上次长久化好的文件(dump.rdb)。整个过程中，主过程不会进行任何IO操作的，这样就可能保障Redis主过程继续的高性能。在复原数据时，重启后会Redis会主动加载工作目录下的dump.rdb文件复原数据到内存

相干参数：

## 设置触发RDB dump的条件，在<seconds>工夫至多产生了<changes>次数据的操作，则<seconds>工夫到了就将数据写到磁盘中，为dump.rdb  Redis默认设置了三个条件，满足之一即可触发。移除所有条件或者设置 save 后加空字符串为禁用RDB性能save <seconds> <changes>save 900 1          ## for 低频写入    save 300 10          ## for 中频写入save 60 10000              ## for 高频写入## 设置当RDB过程呈现故障时，Redis是否进行写操作,默认为yesstop-writes-on-bgsave-error yes## 设置RDB时是否应用LZF压缩算法对dump.rdb文件进行压缩，默认yesrdbcompression yes## 设置是否对dump.rdb文件进行校验，默认CRC64校验算法，会耗费RDB过程的CPU资源的10%，默认开rdbchecksum yes## 设置输入文件名， 默认dump.rdbdbfilename dump.rdb## 设置dump.rdb文件输入门路，默认为以后启动工作目录dir ./

劣势：

  • 无论是长久化过程还是数据恢复过程，RDB的速度都十分快
  • 用户可能手动设置参数以管制长久化的频率，利用场景更加灵便
  • 适宜大规模且对数据的完整性和一致性要求不高的数据恢复，

劣势：

  • RDB的长久化须要fork一条子线程，且子线程将会copy主线程所有数据，相当于设施的内存应用长期翻了一倍，在数据量特地大的状况下应用RDB可能有内存溢出危险
  • 最初一次长久化的数据可能失落，因而对数据完整性比拟敏感的业务不倡议应用RDB进行长久化

PLUS：为什么最初一次长久化的数据可能失落？

RDB通过设置save <seconds> <changes>条件来触发dump，其机制为满足任一save条件后再该条件的<seconds>后进行刷写，但实际上可能最初一次dump时尽管达到批改次数<changes>要求，但在工夫还未达到时redis过程停止，则这一阶段的数据就失落了。比方save 300 10这一条件，Redis在300s内的批改操作次数超过了10次，因而触发长久化条件，零碎将会在300s到期后进行刷写，然而可能在到期前几秒，设施异样关机，那么这300s内产生的数据批改信息将会全副失落

3. AOF(Append Only File)

实现机制：与RDB间接写原数据不同，AOF记录的是Redis自启动期间所有的写操作，相似于日志，且写入的形式只容许在开端追加，不容许批改之前写入的内容，默认保留为appendonly.aof文件。复原数据时，Redis将AOF加载到内存并执行其中的每一条数据进行数据的复原。

相干参数：

## 启动开关  --  默认敞开appendonly no ## 文件名appendfilename "appendonly.aof"## 刷写频率appendfsync always       ## 同步长久化，每当有数据变更就立刻记录到磁盘，性能较差但数据完整性好appendfsync everysec    ## 出厂默认配置，异步操作，每秒记录，如果一秒内宕机，则会有数据失落append no        ## 不设置刷写频率，当Redis本人触发刷写条件时才进行刷写

劣势：

  • 默认的刷写频率为每秒一次，因而可能最大水平地保证数据的完整性
  • AOF只是记录运行时的写操作，并不会复制所有主线程数据，因而产生内存溢出的危险较小

劣势：

  • 只反对追加模式写入，因而造成的appendonly.aof文件会越来越大，会影响Redia复原数据的性能
  • 复原数据时须要Redis执行appendonly.aof记录的每条指令，复原速度较慢
  • 实际上操作指令有很大的整合空间，比方10000条自增1语句能够归并为一条自增10000语句，AOF在这方面依然有较大可优化空间

Rewrite机制：为解决appendonly.aof文件会越来越大的隐患，AOF设置了Rewrite机制，默认当appendonly.aof文件大小达到了上次Rewrite后appendonly.aof文件的大小时并且文件的大小超过64M，AOF将会启动Rewrite，fork出一条新过程创立一个临时文件，而后遍历整个数据库，将每个key、value对以Redis命令的格局输入到临时文件。这一过程会将多个键值对集合起来用一条命令表白以减小最终文件的大小。在rewrite期间的写操作会保留在内存的rewrite buffer中，rewrite胜利后这些操作也会append到临时文件中，rewrite实现后该临时文件便会代替appendonly.aof文件

## 触发Rewrite条件 -- and -- auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb## 产生重写时是否反对appendfsync刷写？ 默认为no，保障数据安全no-appendfsync-on-rewrite no

4. 小结

应用场景：

  • RDB适宜数据流大、数据恢复快但对数据完整性依赖不高的业务，比方用户行为剖析等
  • AOF则适宜对数据完整性有很高限度的业务，比方银行金融类业务

共存性：
官网尽管默认敞开AOF性能，但本质上RDB和AOF是能够共存的，当Redis同时开启了AOF和RDB长久化，Redis重启时会优先读取AOF文件进行数据恢复，因为AOF比RDB更能保障数据完整性。此外，因为Redis数据的复原须要读取AOF文件或者RDB文件，因而，为了避免这两个文件呈现损毁或者被歹意批改，Redis提供了两个修复脚本专门修复这两个文件

## 修复AOF文件redis-check-aof  --fix appendonly.aof## 修复RDB文件redis-check-dump --fix dump.rdb

安全性拓展：
理论生产时，无论是AOF还是RDB，都须要将生成的appendonly.aof和dump.rdb文件进行异地备份，这样能力防止单机彻底损坏造成的数据不可复原问题