Redis04：数据持久化实践-CSDN博客

Redis的持久化机制包括RDB和AOF两种方式。RDB通过快照实现数据持久化，适用于全量备份和高可用场景，但在数据丢失上存在一定风险。AOF则记录所有写操作日志，保证数据不丢失，但文件体积较大，影响写入性能。合理选择和配置持久化策略，可以兼顾数据安全和系统性能。

摘要由CSDN通过智能技术生成

简介

背景

Redis是一种内存数据库，在断电时数据可能会丢失。比如你redis整个挂了，然后redis不可用了，如果没有持久化的话，redis就会丢失所有的数据，如果通过持久化将数据搞一份儿到磁盘上去，然后再定期同步到一些云存储服务上去，那么就可以保证一些数据不丢失，保证数据的可靠性。

持久化方式

Redis中为了保证在系统宕机(类似进程被杀死)情况下，能更快的进行故障恢复，设计了两种数据持久化方案，分别为rdb和aof方式。

Rdb方式持久化

概述

Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。

RDB方式配置

RDB方式的持久化是默认开启的，也可按规则自己配置，例如，打开redis.conf文件，例如

# 这里表示每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting(快照)。

save 60 1000

# 持久化 rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes
    
# 在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。
rdbcompression yes
# 一个CRC64的校验就被放在了文件末尾，当存储或者加载rbd文件的时候会有一个10%左右的性能下降，为了达到性能的最大化，你可以关掉这个配置项。
rdbchecksum yes

# 快照的文件名
dbfilename dump.rdb

# 存放快照的目录
dir /var/lib/redis

Rdb方式持久化实践

退出时备份

shutdown

自动备份

save 900 1 #900s内存了1个数据就备份
save 300 10 #300s内存了10个数据就备份
save 60 10000 #60s内存了10000个数据就备份

手动备份

save

面试小结

redis中的save和bgsave指令由什么区别

Redis save执行一个同步保存操作，当前redis实例的所有数据快照(snapshot)以RDB文件的形式保存到硬盘

BGSAVE命令执行之后立即返回ok，Redis fork产生一个新的子进程，原来的Redis进程继续处理请求，二紫禁城负责存储数据，退出

RDB持久化机制有哪些优点

第一：RDB会生成很多数据文件，每页数据文件都代表某一时刻Redis中的数。这种多个数据文件的方式，非常适合做冷备，将完整的数据源文件发送到远端云服务上去，定期备份redis的数据

第二：RDB对于redis影响很小，可以让redis保持高性能。因为redis主进程只需要fork一个子进程，让子进程执行磁盘io操作来进行RDB持久化即可

第三：相对于AOF持久化机制来说，基于RDB数据文件恢复重启redis进程，更加的迅速

有哪些缺点

RDB并不是立即保存数据，而是隔一段时间做一次快照，而在期间出现了reids宕机，那么会丢失数据

Aof方式数据持久化

概述

Aof方式是通过记录写操作日志的方式,记录redis数据的一种持久化机制,这个机制默认是关闭的。

修改redis.conf

# 是否开启AOF，默认关闭
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种刷写模式：
# appendfsync always #每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
# appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。
    
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

小节面试分析

如何理解AOF方式中的rewrite操作？

redis中的数据也是有限的，很多数据都可能会自动过期，可能会被用户删除了。可能被redis用缓存清楚的算法清理掉。也就是所redis中的数据会不断淘汰掉旧的。只有一部分常用的数据会自动保存在redis之中，所以可能之前很多被清理掉的数据，对应的日志还停留在AOF中，到了AOF中，覆盖之前的老日志；确保AOF日志的文件不会过大，和redis内存数据量一致。