Redis 持久化个人总结

最新推荐文章于 2024-11-06 00:13:21 发布

半个菜鸟_

最新推荐文章于 2024-11-06 00:13:21 发布

阅读量707

点赞数 23

文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/qq_62074445/article/details/137473987

版权

Redis持久化

RDB持久化
AOF持久化
混合持久化

RDB

介绍

介绍：全称Redis Database file（Redis数据备份文件），又称Redis数据快照。

简单说就是把内存种的所有数据都记录到磁盘中，当Redis实例出故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称 RDB文件，默认保存在当前运行目录。
    save #由Redis主进程来执行RDB，会阻塞其他命令
    
    bgsave #开启子进程执行RDB，避免主线程受到影响

如果主动停机，会执行一次RDB。

配置

Redis内部有触发RDB机制，可在redis.conf文件中找到，格式如下：

#900s内，如果至少有一个key被修改，则执行bgsave，如果是save ""，则表示禁用RDB
save 900 1

save 300 10
save 60 10000

RDB的其他配置也可在redis.conf中配置：

#是否压缩，建议不开启，压缩会消耗cpu，磁盘不如cpu值钱
rdbcompression yes

#RDB文件名称
dbfilename dump. rdb

#文件保存的路径目录
dir ./

bgsave底层实现

bgsave开始时会fork（复制）主进程得到子进程，子进程共享进程的内存数据。

完成fork后读取内存数据并写入RDB文件。

fork采用的是cope-on-write计数：

当主进程执行读操作时，访问共享内存。

当主进程执行写操作时，会拷贝一份数据，执行写操作。

总结

RDB方式bgsave的基本流程：

fork主进程得到一个子进程，共享内存空间

子进程读取内存数据并写入新的RDB文件

用新RDB文件替换旧的RDB文件

RDB会在什么时候执行？

默认是服务停止时。

save 60 100 代表什么含义？

代表60秒内至少执行1000次修改触发RDB

RDB的缺点？

RDB执行间隔时间长，两次RDB之间写入数据有丢失风险

fork子进程、压缩、写出RDB文件都比较耗时。

AOF持久化

介绍

AOF全称Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看作命令日志文件。

配置

AOF默认关闭，需要修改redis.conf配置文件来开启AOF：

#是否开启AOF功能，默认是no
appendonly yes
#AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率可以通过redis.conf文件来配置：

#表示每执行一次写命令，立即记录到AOF文件
appendfsync always

#写命令执行完后先放AOF缓冲区，然后表示每隔一秒将缓冲区数据写到AOF文件（默认方案）
appendfsync everysec

#写命令执行完后放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢失数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能适中	可靠性较差，可能丢失大量数据

由于AOF是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只要最后一次有意义。

可以通过 bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到同样的效果。

Redis也会在触发阙值时自动去重写AOF文件。阙值在redis.conf文件中配置：

#AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100

#AOF文件体积最小多大才触发重写
auto-aof-rewrite-min-size 64mb

RDB和AOF对比

如果对数据安全性要求高的，在实际开发中往往会结合两种来使用。

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每次执行的命令（类似日志）
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快（直接使用快照）	慢（AOF文件体积大）
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源，但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟的数据丢失，追求更快的启动速度	对数据安全性要求较高

混合持久化

RDB 优点是数据恢复速度快，但是快照的频率不好把握。频率太低，丢失的数据就会比较多，频率太高，就会影响性能。

AOF 优点是丢失数据少，但是数据恢复不快。

为了集成了两者的优点， Redis 4.0 提出了混合使用 AOF 日志和内存快照，也叫混合持久化，既保证了 Redis 重启速度，又降低数据丢失风险。

Redis 4.0 引入的混合持久化并不是将 RDB 和 AOF 直接混合在一起，而是通过将 RDB 和 AOF 持久化结合起来，利用它们各自的优势来提高数据持久化的可靠性和性能。

具体来说，混合持久化是指在 Redis 4.0 中可以同时启用 RDB 快照和 AOF 日志，而不是替代其中一个。在混合持久化模式下，Redis 会使用 RDB 快照来实现周期性的全量备份，同时使用 AOF 日志来记录每个写操作的指令，以确保数据的实时持久化和恢复。

在写操作的时候，Redis 会先将写操作记录到 AOF 日志中，然后根据配置的条件进行 AOF 日志的刷盘（fsync），以确保写操作的持久化。同时，Redis 也会在配置的条件下周期性地执行 RDB 快照，以创建全量备份。因此，在混合持久化模式下，写操作既会触发 AOF 日志的追加，也可能触发 RDB 快照的生成。

优点：