Redis 速度快,很大一部分原因是因为它所有的数据都存储在内存中。如果断电或者


宕机,都会导致内存中的数据丢失。为了实现重启后数据不丢失,Redis 提供了两种持久


化的方案,一种是 RDB 快照(Redis DataBase),一种是 AOF(Append Only File)。



一、RDB



RDB 是 Redis 默认的持久化方案。当满足一定条件的时候,会把当前内存中的数



据写入磁盘,生成一个快照文件 dump.rdb。Redis 重启会通过加载 dump.rdb 文件恢



复数据




RDB 触发




1、自动触发



a)配置规则触发。



redis.conf, SNAPSHOTTING,其中定义了触发把数据保存到磁盘的触发频率。



如果不需要 RDB 方案,注释 save 或者配置成空字符串""。




save 900 1 # 900 秒内至少有一个 key 被修改(包括添加)



save 300 10 # 400 秒内至少有 10 个 key 被修改



save 60 10000 # 60 秒内至少有 10000 个 key 被修改




注意上面的配置是不冲突的,只要满足任意一个都会触发




RDB 文件位置和目录:




# 文件路径,



dir ./



# 文件名称



dbfilename dump.rdb



# 是否是 LZF 压缩 rdb 文件



rdbcompression yes



# 开启数据校验



rdbchecksum yes




RDB 还有两种触发方式:



b)shutdown 触发,保证服务器正常关闭。



c)



flushall,RDB 文件是空的,没什么意义(删掉 dump.rdb 演示一下)。




2、手动触发




如果我们需要重启服务或者迁移数据,这个时候就需要手动触 RDB 快照保存。Redis



提供了两条命令:



1)save



save 在生成快照的时候会阻塞当前 Redis 服务器, Redis 不能处理其他命令。如果



内存中的数据比较多,会造成 Redis 长时间的阻塞。生产环境不建议使用这个命令。



为了解决这个问题,Redis 提供了第二种方式。 咕泡出品,必属精品 www.gupaoedu.com



2)bgsave



执行 bgsave 时,Redis 会在后台异步进行快照操作,快照同时还可以响应客户端请



求。



具体操作是 Redis 进程执行 fork 操作创建子进程(copy-on-write),RDB 持久化



过程由子进程负责,完成后自动结束。它不会记录 fork 之后后续的命令。阻塞只发生在



fork 阶段,一般时间很短。



用 lastsave 命令可以查看最近一次成功生成快照的时间




RDB 文件的优势和劣势



优势



1.RDB 是一个非常紧凑(compact)的文件,它保存了 redis 在某个时间点上的数据



集。这种文件非常适合用于进行备份和灾难恢复。



2.生成 RDB 文件的时候,



redis 主进程会 fork() 一个子进程来处理所有保存工作,主



进程不需要进行任何磁盘 IO 操作。



3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。



劣势



1、RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要



执行 fork 操作创建子进程,频繁执行成本过高。



2、在一定间隔时间做一次备份,所以如果 redis 意外 down 掉的话,就会丢失最后



一次快照之后的所有修改(数据有丢失)。



如果数据相对来说比较重要,希望将损失降到最小,则可以使用 AOF 方式进行持久



化。





AOF




AOF:Redis 默认不开启。AOF 采用日志的形式来记录每个写操作,并 追加 到文件 中。开启后,执行更改 Redis 数据的命令时,就会把命令写入到 AOF 文件中。 Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作




AOF 配置



配置文件 redis.conf



# 开关



appendonly no



# 文件名



appendfilename "appendonly.aof





appendonly :Redis 默认只开启 RDB 持久化,开启 AOF 需要修改为 yes



appendfilename "appendonly.aof"  :路径也是通过 dir 参数配置 config get dir




appendfsync everysec:



AOF 持久化策略(硬盘缓存到磁盘),默认 everysec




no:  表示不执行 fsync ,由操作系统保证数据同步到磁盘,速度最快,但是不太安全;




always:  表示每次写入都执行 fsync ,以保证数据同步到磁盘,效率很低;




everysec:  表示每秒执行一次 fsync ,可能会导致丢失这 1s 数据。通常选择 everysec ,



兼顾安全性和效率。




AOF 优势与劣势



优点:



AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步



一次,Redis 最多也就丢失 1 秒的数据而已。



缺点:



1.对于具有相同数据的的 Redis,AOF 文件通常会比 RDF 文件 体积更大 (RDB



存的是数据快照)。



2.虽然 AOF 提供了多种同步的频率,默认情况下,每秒同步一次的频率也具有较



高的性能。在高并发的情况下,RDB 比 AOF



具好更好的性能保证。