Redis持久化

什么是持久化

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化
持久化用于防止数据的意外丢失，确保数据安全性

持久化过程保存什么

RDB 数据（日志）

10011001110000001 00101001011010110 10110011001110000 00100101001011011

AOF 过程 （快照）

删除第3行 第4行末位添加字符x 删除第2到第4行 复制第3行粘贴到第5行

RDB

save指令进行手动RDB过程
手动执行一次保存操作

save

RDB启动方式 —— save指令相关配置
设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb

dbfilename filename

设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

dir path

设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大

rdbcompression yes|no

设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，但存在数据损坏的风险

rdbchecksum yes|no

redis.conf

bind 192.168.135.132
port 6381
# Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
daemonize no
# 因为redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no
#logfile "6379.log"
dir /redis/data
dbfilename "dump-6381.rdb"
requirepass 123456

rdb文件就会存储redis的key-value值。

save指令原理
客户端1:127.0.0.1：6379> set key1 value1

客户端2:127.0.0.1：6379> set key2 value2

客户端3:127.0.0.1：6379> save

客户端4:127.0.0.1：6379> get key1

上面的执行过程：get → save → set → set（单线程任务执行序列）
注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
bgsave指令进行手动RDB过程
RDB启动方式 —— bgsave指令
手动启动后台保存操作，但不是立即执行

bgsave

RDB启动方式 —— bgsave指令相关配置
后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

stop-writes-on-bgsave-error yes|no

其他

dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no

停止redis前

停止redis后

bgsave原理

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

save配置进行自动RDB过程

RDB启动方式 ——save配置
设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

save second changes

参数
second：监控时间范围
changes：监控key的变化量

save 900 1
save 300 10
save 60 10000

注意： save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
save配置启动后执行的是bgsave操作
三种方式对比（优缺点）

RDB特殊启动形式

服务器运行过程中重启

debug reload

关闭服务器时指定保存数据

shutdown save

RDB优点
RDB是一个紧凑压缩的二进制文件，存储效率较高
RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
RDB恢复数据的速度要比AOF快很多
应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点
RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

RDB存储的弊端
存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
大数据量下的IO性能较低
基于fork创建子进程，内存产生额外消耗
宕机带来的数据丢失风险

AOF

◆ AOF概念

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令
达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

启动AOF相关配置

开启AOF持久化功能，默认no，即不开启状态

appendonly yes|no

AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

appendfilename filename

AOF持久化文件保存路径，与RDB持久化文件保持一致即可

dir

AOF写数据策略，默认为everysec

appendfsync always|everysec|no

◆ AOF执行策略

AOF写数据三种策略(appendfsync)

always(每次）：每次写入操作均同步到AOF文件中
数据零误差，性能较低，不建议使用。
everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据
数据准确性较高，性能较高，建议使用，也是默认配置
no（系统控制）：由操作系统控制每次同步到AOF文件的周期
整体过程不可控

◆ AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重
写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结
果转化成最终结果数据对应的指令进行记录。

AOF重写作用
降低磁盘占用量，提高磁盘利用率
提高持久化效率，降低持久化写时间，提高IO性能
降低数据恢复用时，提高数据恢复效率

◆ AOF工作原理

进程内具有时效性的数据，并且数据已超时将不再写入文件
非写入类的无效指令将被忽略，只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
对同一数据的多条写命令合并为一条命令
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式

手动重写

bgrewriteaof

自动重写

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）

aof_current_size
aof_base_size

RDB与AOF区别

RDB与AOF的选择之惑

对数据非常敏感，建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
数据呈现阶段有效性，建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
综合比对
RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF

如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
灾难恢复选用RDB
双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量