核心内容摘要
企业级Linux环境下软件包兼容性问题的深度解析与解决方案
简介Redis的高性能是由于其将所有数据都存储在了内存中为了使Redis在重启之后仍能保证数据不丢失需要将数据从内存中同步到硬盘中这一过程就是持久化。
Redis支持两种方式的持久化一种是RDB方式一种是AOF方式。
可以单独使用其中一种或将二者结合使用。
RDB定期快照式存储RDB方式的持久化是通过**快照**snapshotting完成的当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。
RDB是Redis默认采用的持久化方式主从复制的时候默认使用的为RDB。
生成的文件通常是dump.rdb工作原理内存数据 → fork子进程 → 子进程写入RDB文件 → 替换旧文件触发方式自动触发#
自动触发配置文件中设置 save9001#900秒内至少有1个key改变 save30010#300秒内至少有10个key改变 save6010000#60秒内至少有10000个key改变含义900 秒内有 1 次写 → 生成快照300 秒内有 10 次写60 秒内有 10000 次写在redis.conf中配置dir指定rdb快照文件的位置配置dbfilenam指定rdb快照文件的名称手动触发#
手动触发 redis-cliSAVE # 同步保存阻塞其他操作 redis-cliBGSAVE # 后台异步保存推荐RDB 优缺点优点✅ 文件紧凑适合备份和灾难恢复✅ 恢复大数据集时速度比AOF快✅ 最大化Redis性能父进程无需磁盘IO✅ 支持子进程写时复制Copy-On-Write不阻塞线程主从复制的时候会遗漏一部分最后通过offset补齐缺点❌ 可能丢失最后一次快照后的数据❌ fork子进程时内存占用翻倍❌ 大数据集时fork可能耗时较长
AOF追加日志是存储工作原理默认情况下Redis没有开启AOFappend only file方式的持久化可以通过appendonly参数开启appendonly yes开启AOF持久化后每执行一条会更改Redis中的数据的命令Redis就会将该命令写入硬盘中的AOF文件。
AOF文件的保存位置和RDB文件的位置相同都是通过dir参数设置的默认的文件名是appendonly.aof可以通过appendfilename参数修改appendfilename appendonly.aof。
AOF的工作流程**命令追加append**所有的写命令会追加到 AOF 缓冲区中。
**文件写入write**将 AOF 缓冲区的数据写入到 AOF 文件中。
注意此时并没有同步到磁盘。
**文件同步fsync**fsync 将阻塞直到写入磁盘完成后返回保证了数据持久化。
**文件重写rewrite**随着 AOF 文件越来越大需要定期对 AOF 文件进行重写达到压缩的目的。
**重启加载load**当 Redis 重启时可以加载 AOF 文件进行数据恢复AOF 重写机制# 解决AOF文件过大的问题 # 通过重写创建当前数据集的最小命令集合 # 触发重写 auto-aof-rewrite-percentage100# 文件增长100%时重写 auto-aof-rewrite-min-size64mb # 最小64MB才重写 # 手动重写 redis-cliBGREWRITEAOFAOF 同步策略# redis.conf 配置 appendonly yes # 开启AOF appendfilenameappendonly.aof# AOF文件名 # 同步策略重要 appendfsync always # 每个写命令都同步最安全但性能差 appendfsync everysec # 每秒同步一次推荐平衡安全与性能 appendfsync no # 由操作系统决定最快但可能丢失数据策略数据安全性能always最安全最慢everysec较安全推荐no风险高最快AOF 配置详解# redis.conf 完整AOF配置 appendonly yes appendfilenameappendonly.aofappendfsync everysec # AOF重写配置 no-appendfsync-on-rewrite no # 重写时是否停止fsync auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb # 加载时处理损坏的AOF aof-load-truncated yes # 加载截断的AOF文件 aof-use-rdb-preamble yes # 混合持久化Redis
0AOF 优缺点优点✅ 数据安全性更高最多丢失1秒数据✅ 可读的日志文件便于分析✅ 仅追加写入无磁盘寻址开销✅ 支持后台重写不影响客户端缺点❌ 文件体积通常比RDB大❌ 恢复速度比RDB慢❌ 性能略低于RDB取决于fsync策略❌ 可能遇到AOF重写bug
混合使用RDBAOFRedis支持两者同时开启工作原理BGREWRITEAOF → 先写RDB快照到AOF文件 → 追加期间的AOF命令不同场景推荐#
数据安全最重要 appendonly yes appendfsync always # 或 appendfsync everysec频繁的RDB备份 #
性能最重要 appendonly no save9001# 较少的RDB备份 #
内存有限需要快速重启 appendonly no dbfilename dump.rdb rdbcompression yes #
推荐的生产配置平衡型 appendonly yes appendfsync everysec auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb save9001save30010save6010000优先使用AOF 恢复数据RDB 作为备份手段这是生产环境的推荐方案。
#