[ Redis篇05] 持久化机制的秘密

Redis 提供两种持久化机制 RDB 和 AOF 机制:

• RDB(Redis Database)

  • 以数据集快照形式保存在一个二进制dump.rdb文件
  • 通过配置 save 属性， 定时执行 ，会fork 子进程来完成写操作，不影响主进程服务，保证了 redis的高性能
  • 相比AOF 数据恢复更快

• 数据安全性低。间隔一段时间进行持久化，若发生故障可能会存在间隔时间内的丢失。

• AOF (Append-only fifile)

  • 记录所有的命令记录 , 保存为 aof 文件。
  • 已追加的默认写入日志文件，省去了磁盘寻址的开销 (append-only 的模式)
  • 通过配置 appendfsync 属性，可配置只有有数据变更就写入。
  • 同样的数据AOF 文件比 RDB 文件大，且恢复速度慢。

• 两种都开启 , 4.0版本开始支持混合持久化功能，默认默认是关闭的，

可以通过 aof-use-rdb-preamble 配置参数控制该功能的启用。5.0 版本 默认开启。

# 必须同时设置 aof-use-rdb-preamble为yes ,开启 AOF持久化方式。
aof-use-rdb-preamble yes 

恢复时先加载AOF文件中的RDB部分，然后再加载AOF文件部分。（既保证了速度）

混合持久化流程

• 混合持久化开启，系统根据策略触发aof rewrite时，
• fork 一个子线程将内存数据以RDB二进制格式写入AOF文件头部，
• 在重写操作执行之后执行的 Redis 命令，则以AOF持久化的方式追加到AOF文件的末尾。

Redis 在长期运行的过程中，AOF 的日志会变的冗长。所以需要对 AOF 日志 "瘦身"。

当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集。

Redis 提供了** bgrewriteaof  **指令用于对 AOF 日志进行瘦身。

举例：
使用redis每次+1自增 到10000，对应命令是累加10000次，
Aof重写就是在恢复时候直接设置 set key，10000，
作用是，减少磁盘占用，加快恢复速度

原理大概是

• 开辟一个子进程，遍历新进程的内存中数据，每条记录有一条的Set语句
• 记录到一个新的 AOF 日志文件中(先写临时文件最后再rename)
• 序列化完毕后再将操作期间发生的增量 AOF 日志
• 追加到这个新的 AOF 日志文件中，
• 追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

5.1自动重写
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

no-appendfsync-on-rewrite yes   #在日志重写时，不进行命令追加操作
auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
auto-aof-rewrite-min-size 64mb  #启动新的日志重写过程的最小值

5.2. 手动后台重写：通过BGREWRITEAOF手动重写

RDB持久化配置

#文件名
dbfilename dump.rdb
#生成的文件所在目录，默认启动目录
dir ./
#在900秒(15分钟)之后，若有1个key发生变化，则dump内存快照。
save 900 1  
#在300秒(5分钟)之后，若至少有10个key发生变化，则dump内存快照。    
save 300 10  
#在60秒(1分钟)之后，若至少有10000个key发生变化，则dump内存快照。          
save 60 10000 

AOF持久化配置

# 默认关闭
appendonly no
# 文件名
appendfilename "appendonly.aof"

在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always     #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec    #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no          #从不同步。高效但是数据不会被持久化。

混合模式记得开启配置

# 必须同时设置 aof-use-rdb-preamble为yes ,开启 AOF持久化方式。
aof-use-rdb-preamble yes