关于redis:Redis持久化之RDB-AOF

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 是否进行写操作, 默认为 yes
stop-writes-on-bgsave-error yes

## 设置 RDB 时是否应用 LZF 压缩算法对 dump.rdb 文件进行压缩，默认 yes
rdbcompression yes

## 设置是否对 dump.rdb 文件进行校验，默认 CRC64 校验算法，会耗费 RDB 过程的 CPU 资源的 10%，默认开
rdbchecksum yes

## 设置输入文件名，默认 dump.rdb
dbfilename 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 100
auto-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 文件进行异地备份，这样能力防止单机彻底损坏造成的数据不可复原问题