### 课堂目标 1. 理解redis的两种持久化的方式 2. RDB和AOF区别 3. 如何进行配置 # 一、redis持久化 什么叫持久化？把数据保存在磁盘，保证不丢失 # 二、redis持久化方式 !\[image-20251012002323652\](https://woniumd.oss-cn-hangzhou.aliyuncs.com/daiwei/java/20260202121115845.png) ## 1、RDB方式 !\[image-20251012003636288\](https://woniumd.oss-cn-hangzhou.aliyuncs.com/java/daiwei/20251012003636381.png) 整体流程： 1、主进程会开启一个子进程去进行数据备份，不会影响主进程的读写操作（因为是单独的一个进程） 2、子进程是以定时的方式，把内存中的数据，写入到磁盘(可配置) 3、也可以手动去调用bgsave(生产上用BGSAVE异步操作不会阻塞读写)或save(同步操作对读写有影响)去手动备份 4、整个过程不影响数据的使用，因为用户访问的数据都是在内存里面 RDB的优缺点： 1、RDB备份是二进制文件，相对文件内容更加紧凑，文件大小更小；速度更快， 2、因为是间隔一定时间进行全量备份，有可能导致数据的丢失 \`\`\` ################################ SNAPSHOTTING 快照配置 ################################ # 在指定的时间间隔内，如果发生了指定数量的写操作，则自动触发BGSAVE生成RDB快照 # 格式：save # 可以配置备份策略，多个条件，满足任意一条就会触发 save 900 1 # 900秒（15分钟）内至少有1个key被改变 save 300 10 # 300秒（5分钟）内至少有10个key被改变 save 60 10000 # 60秒内至少有10000个key被改变 # 如果持久化出错，是否停止接收写操作（推荐开启，保证数据一致性） stop-writes-on-bgsave-error yes # 导出RDB文件时是否使用LZF压缩（压缩会消耗CPU，但大幅减少文件体积） rdbcompression yes # 从Redis 5.0开始，使用CRC64算法进行数据校验，牺牲约10%性能换取数据安全 rdbchecksum yes # RDB文件名（可自定义） dbfilename dump.rdb # RDB文件和工作目录（AOF文件也会存在这里） # 必须是Redis进程有写权限的目录 dir /var/lib/redis/6379 # 从Redis 7.0开始新增：是否在RDB文件中包含副本 # 当从节点执行全量同步时，会先生成临时RDB文件，此选项控制是否保留 rdb-save-incremental-fsync yes # 自动触发BGSAVE时，如果上次持久化失败，是否继续触发（默认yes） # 如果设为no，则上次失败后，自动触发将停止，直到手动执行成功一次 # rdb-del-sync-files no \`\`\` 手动备份 \`\`\` # 在 redis-cli 中执行，立即开始后台保存 save是阻塞命令，生产上不可执行 127.0.0.1:6379\> BGSAVE Background saving started # 看到这个提示，说明已开始 \`\`\` \`\`\` # 查看最近一次成功保存的时间 127.0.0.1:6379\> LASTSAVE (integer) 1649385672 # 返回 Unix 时间戳，可转换为人类可读时间 \`\`\` ## 2、AOF方式 每次写入命令都作为\*\*日志\*\*形式，\*\*追加到一个日志文件中\*\*，redis启动的时候，可以通过\*\*AOF日志\*\*，重新构建数据。(指定回放) AOF是增量备份 3中策略 日志优化 !\[image-20251012004818376\](https://woniumd.oss-cn-hangzhou.aliyuncs.com/java/daiwei/20251012004818470.png) 1、首先写入数据到缓冲区 2、有3中方式进行\*\*AOF日志文件\*\*的写入，一般情况定\*\*时1秒\*\*（最多丢失1秒的数据） 3、AOF日志有一个优化器，对于无效的指令进行瘦身，以提高启动时的加载效率 AOF的优缺点： 1、数据相对更加可靠，AOF记录了所有的SET指令，可以直接执行这些指令回复数据 2、文件大、恢复慢；记录了所有的set指令，一条一条执行 # 同步策略，推荐使用每秒同步 进入redis.conf文件进行配置 appendfsync everysec \| 策略 \| 数据完整性 \| 性能 \| 场景 \| \| -------- \| ------------------------------------------------------------ \| ------------------------------------------------------------ \| ------------------------------------------------------ \| \| always \| 最高 每次写操作都立即刷盘，宕机时仅可能丢失最后一个写操作。 \| 最大 因为每次写操作都会阻塞直到数据写入硬盘，吞吐量较低。 \| 对数据可靠性要求极高的场景，如金融交易。 \| \| everysec \| \*\*较高\*\* 每秒刷盘一次，宕机时最多丢失1秒内的数据。 \| \*\*较小\*\* 刷盘操作由后台线程执行，对性能影响相对较小，QPS仍可上万。 \| \*\*生产环境常用配置\*\*，在性能和数据安全间取得良好平衡。 \| \| no \| \*\*最低\*\* 刷盘时机交由操作系统决定（通常约30秒），宕机可能丢失较多数据。 \| \*\*最小\*\* Redis不主动刷盘，性能最高。 \| 对性能要求极高，且可容忍部分数据丢失的场景，如缓存。 \| \`\`\` # 启用AOF持久化 appendonly yes # AOF文件名 appendfilename "appendonly.aof" # 同步策略，推荐使用每秒同步 appendfsync everysec # 重写AOF时是否进行同步，通常设置为no，以避免重写时的磁盘I/O竞争 no-appendfsync-on-rewrite no # 自动重写AOF的配置 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 加载AOF时，如果AOF文件被截断，是否继续加载 aof-load-truncated yes # 使用RDB和AOF混合格式（Redis 4+） aof-use-rdb-preamble yes \`\`\`