Redis持久化记录一下

前言

• redis在项目中是经常会使用的一种缓存数据库，了解其一些配置和设计思路有利于我们更有效安全的使用它
• 这次分析一下redis的数据持久化机制，知其然知其所以然。

解析过程

RDB快照处理

• 在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中
• 可以对Redis进行设置，让它在“N秒内数据至少有M个改动”这一条件被满足，自动保存一次数据快照。
• 在Redis的默认配置如下:

save 900 1
save 300 10
save 60 10000

• 其意思是Redis满足：900秒内有一个数据被改动，或300秒内有10个数据被改动，或60秒内有10000个数据被改动条件，就会执行RDB持久化保存数据快照。
• 除了自动满足触发条件进行RDB持久化外，还可以手动命令执行生成RDB快照，在Redis客户端执行save或者bgsave命令会生成dump.rdb文件。
• 每次命令执行都会将所有redis内存数据快照到一个新的dump.rdb文件，并覆盖原有rdb快照文件。

bgsave-写时复制机制

• Redis借助操作系统提供的写时复制机制（copy-on-write，cow），在生成快照的同时，依然可以处理客户端的读写操作命令。简单来说，bgsave子进程是由主进程fork生成的，可以共享主线程的所有内存数据。
• bgsave子进程运行后，会开始读取主进程的内存数据并写入RDB文件。此时如果主进程是一些对数据的读操作，那么主进程和子进程互不影响。但如果主进程对数据进行写操作，那么这块被写入的数据被会复制一份，然后子进程把复制的备份写入到RDB文件中，而这个过程中主进程是依旧可以对客户端进行读写操作的。

save和bgsave对比

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其他命令	是	否（在主进程生成子进程调用fork函数时会有短暂阻塞）
复杂度	O(N)	O(N)
优点	不会消耗额外内存	不会阻塞客户端命令
缺点	阻塞客户端命令	fork子进程，消耗内容

• 注意：配置自动生成rdb文件redis使用的是bgsave方式。

AOF 持久化机制

• 使用RDB快照持久化数据，会因为redis宕机或其他故障原因，导致服务器将会丢失掉最近插入且未保存到rdb文件的数据。所以从Redis 1.1版本后，Redis新增一种 AOF持久化机制，将修改的买一条指令都记录到appendonly.aof中（先写入os cache，在隔一段时间fsync到磁盘）
• 比如执行命令"set iamzrh 24"，aof文件记录如下：

*3
$3
set
$6
iamzrh
$2
24

• 这是一种resp协议格式数据，* 后面数字代表有多少个参数，$后面数字代表参数的字符。
• 可以通过修改配置文件来打开AOF持久化

appendonly yes

• 每当Redis执行一个写命令时，例如set，这个命令就会添加到AOP文件末尾。当Redis重启时，程序可以通过执行AOF文件的命令来达到重建数据库的目的。
• 关于配置Redis多久才将数据fsync到磁盘中，可以通过以下三个命令配置：

# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.

# appendfsync always
appendfsync everysec
# appendfsync no

• always：每次有新的命令追加到AOF文件就执行一次fsync，效率低，但数据安全。
• everysec（推荐）：每秒fsync一次，效率较高，产生故障只丢失一秒数据，这种策略兼顾速度与安全。
• no：从不fsync，将数据交给操作系统处理，更快也更不安全。

AOF 重写

• AOF文件可能存在很多没用的指令，所以AOF会定期根据内存的最新数据身材AOF文件。

redis-6379:0>incr iamzrh
(integer) 1
redis-6379:0>incr iamzrh
(integer) 2
redis-6379:0>incr iamzrh
(integer) 3
redis-6379:0>incr iamzrh
(integer) 4
redis-6379:0>incr iamzrh
(integer) 5
redis-6379:0>incr iamzrh
(integer) 6

• 重写后AOF文件变成

*3
$3
SET
$6
iamzrh
$1
6

• 以下两个配置可以控制AOF自动重写的频率：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• aof文件自上一次重写后文件大小增长了100%会触发重写。
• aof文件要达到64M才会重写。
• AOF还可以手动执行重写，在Redis客户端执行命令bgrewriteaof重写AOF，注意：aof重写redis会fork一个子进程去做，不会阻塞redis客户端读写命令。

RDB和AOF比较

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢数据	根据策略决定

Redis 4.0 混合持久化

• 在Redis重启时，很少使用RDB来恢复内存，因为可能会丢失大量数据。所以通常使用AOF文件恢复数据，但AOF文件恢复shuj相对于RDB来说要很慢，在Redis实例多的情况下，启动可能会话费大量时间。
• Redis 4.0为解决这个问题，推出一种新的持久化机制-混合持久化。可以通过如下配置开启混合持久化配置（必须先开启aof）:

aof‐use‐rdb‐preamble yes

• 开启混合持久化后，在AOF重写是，不再单纯将内存数据转化为RESP命令写入AOF文件，而是将重写这一刻之前的内存作为RDB快照，并且将RDB快照和增量的AOF修改内存数据的命令存放在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
• 在Redis重启时，可以先加载RDB文件，然后在重放增量的AOF日志就可以完全替代之前的AOF全量数据重放，因此启动效率得到提示。
• 混合持久化AOF文件格式如下：

Redis数据备份的策略

• 写crontab定时调度脚本，每小时copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
• 每天都保留一份当日数据到一个目录中，可以保留最近1个月备份
• 每次copy备份时，把太旧的数据删除
• 每天晚上将当前机器的数据备份到另一台机器，防止机器损坏

最后

• 虚心学习，共同进步 -_-