redis持久化

最新推荐文章于 2024-10-02 05:39:15 发布

123小个子

最新推荐文章于 2024-10-02 05:39:15 发布

阅读量117

点赞数

文章标签： redis

本文链接：https://blog.csdn.net/qq_43012301/article/details/104390739

版权

redis的数据都是保持在内存中，如电脑重启、服务挂机等导致重启服务，数据都将丢失
redis的持久化是对数据的更新异步的保存在磁盘上。redis服务启动，将保存在磁盘上的数据读取到内存中，实现持久化。
redis持久法的方式主要为两种：快照（rdb）；写日志（aof）；

rdb原理

rdb实现持久化主要是将当前进程中的数据生成快照保存到硬盘上，在重启的时候读取硬盘上的数据（如果同时配置了aof，将会先执行aof策略，因为aof的实时性比较高），在执行载入rdb文件时，redis会对rdb文件进行检查，在文件损坏等其它情况，日志将会报错，redis启动也将失败

rdb触发条件

手动触发

客户端可以通过手动执行命令save或bgsave实现触发rdb文件写入，成功之后将会创建一个rdb文件（可通过配置’dbfileName’设置文件名）
1. save：同步命令，当在执行写入操作的时候，redis主进程将会阻塞，直到写入成功；当已存在rdb文件的时候，新文件将会替换老的文件，复杂度o(n)
2. bgsave: 利用redis中fork（主进程fork过程是同步的，同时内存越大，耗时越长）函数生成一个子进程，子进程异步生成（createRDB）rdb二进制文件；当已存在rdb文件的时候，新文件将会替换老的文件，复杂度o(n)
命令/特性 save bgsave
io类型同步异步
阻塞是否
复杂度 O(n) O(n)
优点不会消耗额外内存不阻塞客户端命令
缺点阻塞客户端命令需要fork，消耗内存

命令/特性	save	bgsave
io类型	同步	异步
阻塞	是	否
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork，消耗内存

自动触发

redis提供配置命令实现自动生成rdb文件

save 900 1 // 在900秒中数据有1次改变将会生成rdb文件
save 300 10 // 在300秒中数据有10次改变将会生成rdb文件
save 60 10000 // 在60秒中数据有10000次改变将会生成rdb文件

redis满足任意一项都会执行

其他
- 全量复制：在配置了主从节点的时候，通常从节点第一次从主节点那获取数据的时候，都将触发全量复制；
- debug reload
- shutdown

rdb配置

save second changes // 在second秒中数据有changes次改变将会生成rdb文件
dbfilename dump.rdb // 设置rdb文件名（默认dump.rdb）
dir ./ // 设置生成文件存放目录（默认当前目录）
stop-writes-on-bgsave-error-yes yes // 设置是否在bgsave错误是停止写入（默认开启）
rdbcompression yes // 是否压缩rdb文件（默认是）
rdbchecksum yes // 是否执行rdb检验

aof原理

aof主要根据日志实现持久化（自我理解：类似客户端执行写入命令时，aof就保存什么写入命令，redis服务重启时载入aof文件就相当于执行aof保存的每一条命令），redis在执行写命令时，没有立马就写入aof文件，他会先写一个缓冲区，再根据我们配置的appendfsync的策略刷新到aof文件中

aof触发条件

aof触发主要时根据配置的三种策略

always：没执行一条写入命令的时候都将把日志写入到aof文件里面
everysec: 每一秒执行把一秒执行的写入命令一次写入aof文件（推荐）
no：根据操作系统

命令	always	everysec	no
优点	不丢失数据	每秒一次fsync	不用管
缺点	IO开销较大，一般的sata盘只有几百tps	丢一秒数据	不可控

aof重写

为什么需要aof重写

在使用aof实行持久化的时候，并发量变大，或时间的推移，会造成我们的aof文件越变越大，而aof文件变大则会影响我们redis启动载入aof的时间，所有有了aof重写，
过程

主要就是把过期的、重复的、可优化的数据进行化简。
作用

可以减少硬盘的占用，同时redis服务启动时可用提高速度
方式

手动触发：客户端发送bgrewriteaof命令，服务端将fork一个子进程，异步执行aof重写（此时的重写是对redis中的数据进行回溯）。

配置触发：可以通过redis配置文件配置auto-aof-rewrite-min-size（aof文件重写需要的尺寸）、auto-aof-rewrite-percentage（aof文件增长率）实现，同时提供aof_current_size(aof当前尺寸，单位为字节)、aof_base_size(aof上次启动重写的尺寸，单位字节)来进行统计：

什么时候触发:
- aof_current_size > auto-aof-rewrite-min-size
- aof_current_size - aof_base_size / aof_base_size > auto-aof-rewrite-percentage

aof配置

appendonly yes // 开启aof持久化设置
appendfilename appendonly.aof // 设置aof文件名（默认dump.rdb）
appendfsync everysec // 配置aof写入策略
dir ./ // 设置生成文件存放目录（默认当前目录）
no-appendfsync-on-rewrite yes //
auto-aof-rewrite-min-size // aof重写触发策略（设置最小触发aof重写aof文件大小）
auto-aof-rewrite-percentage // aof重写触发策略（设置此时文件达到上传触发重写aof文件大小的多少百分比）

aof与rdb对比

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

总结

rdb实行持久化的话，我们是不可控的，会造成数据的丢失；在开启子进程（fork）时，会造成内存的销毁，并且写入时IO操作，会消耗IO性能，一般关闭rdb是用aof持久化。aof写入策略一般建议使用everysec。启用rdb的时候，maxmemory最好设置为系统可用内存的45%，因为快照时需要一倍的内存来复制整个数据集，就是说相当于90%（45% + 45%），剩余10%内存以防进行其他内存消耗操作（列如：bgsave、aof重写的fork）。如果没开启快照功能，maxmemory最高能设置为系统可用内存的90%。