Redis学习之：Redis的持久化

1.什么是持久化？

Redis的所有数据保存在内存中，对数据异步的更新保存到磁盘上称之为Redis的持久化。内存中的数据会因为关机或断电而丢失，使用持久化可以有效解决数据丢失的问题

2.持久化方式

Redis的持久化方式有以下两种：

RDB（快照）

将Redis中的数据通过一条命令可以生成一个快照，在硬盘上生成一个rdb文件

触发机制

• save（同步）：如果数据量非常庞大，使用save会造成严重阻塞，此时Redis不能正常响应客户端，线上环境禁用
• bgsave（异步）：使用linux的fork命令，生成一个Redis的子进程，由子进程完成快照的生成。一般来说是不会阻塞主线程的，可以正常响应客户端，除非fork非常慢
• 自动（某些条件达到的时候，自动触发）：Redis默认自动生成RDB文件的规则是 900秒中有1条改变、300秒中有10条改变、60秒中有10000条改变

save和bgsave

命令	save	bgsave
IO类型	同步	异步
是否阻塞	是	是（阻塞发生在fork期间）
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork，消耗内存

最佳配置

配置名称	默认配置	推荐配置
save	save 900 1 save 300 10 save 60 10000	X
dbfilename	dbfilename dump.rdb	dbfilename dump-${port}.rdb
dir	dir ./	dir /bigdiskpath
stop-writes-on-bgsave-error	stop-writes-on-bgsave-error yes	stop-writes-on-bgsave-error yes
rdbcompression	rdbcompression yes	rdbcompression yes
rdbchecksum	rdbchecksum yes	rdbchecksum yes

RDB的问题

• 耗时、耗性能（将所有数据dump到硬盘当中）
• 不可控、丢失数据（在高并发写入场景下，即使刚刚进行了bgsave操作，可能1秒钟之内又收到了很多个写操作，此时刚好宕机，则会造成数据丢失）

AOF（日志）

将客户端的每一次写命令以日志形式追加到AOF文件中，几乎不会造成数据丢失
写命令先将命令写入到缓冲区，根据某些策略将缓冲区数据写入到硬盘中

AOF的三种策略

命令	always（每条）	everysec（每秒）	no（由操作系统决定）
优点	不丢失数据	每秒进行一次写操作，	不用管
缺点	IO开销较大，一般的sata硬盘只有几百TPS	最多丢失1秒数据	不可控

AOF的重写机制

AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流逝一定会越来越大。影响包括但不限于：对于Redis服务器，计算机的存储压力、AOF还原出数据库状态的时间增加
为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多

• bgrewriteaof（命令）
• AOF重写配置（配置）
  • auto-aof-rewrite-percentage AOF文件增长率，默认100
  • auto-aof-rewrite-min-size AOF文件重写需要的大小，默认64mb

AOF重写流程

AOF配置

appendonly yes # 开启aof
ppendfilename "appendonly-${port}.aof"  # aof文件名
appendfsync everysec  #生成机制  每秒
dir /bigdiskpath   # aof文件存储路径
no-appendfsync-on-rewrite yes   # aof重写时，是否要做正常的aof操作，yes表示不做。因为重写时非常消耗性能的，也就是说这段时间是否允许丢失数据
auto-aof-rewrite-percentage # AOF文件增长率，默认100
auto-aof-rewrite-min-size # AOF文件重写需要的大小，默认64mb

RDB与AOF对比

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