AOF

一、引子：Redis宕机后数据去哪了？ Redis是内存数据库，数据存储在内存中。那么问题来了：Redis宕机后，数据还在吗？ 1.1 场景：双11大促数据丢失事故 场景：电商网站，双11大促 00:00:00 - 大促开始，流量暴增 00:00:01 - Redis缓存：10万个商品详情、50万个用户Session 00:05:00 - 服务器断电（机房故障） 00:05:01 - Redis进程被杀，内存数据全部丢失 00:10:00 - 服务器恢复，Redis重启 00:10:01 - Redis启动成功，但数据为空！ 问题： 1. 所有商品详情缓存丢失 → 10万次数据库查询 2. 所有用户Session丢失 → 50万用户被强制登出 3. 缓存预热需要10分钟 → 数据库压力巨大 4. 用户体验极差 → 大量用户流失 损失： - 用户流失：50万用户 × 10% = 5万用户 - 订单损失：5万用户 × 20% = 1万单 - GMV损失：1万单 × 200元 = 200万元 核心问题：Redis是内存数据库，断电后数据丢失，需要持久化。 1.2 持久化的本质 持久化：将内存中的数据保存到磁盘，重启后可以恢复。 为什么需要持久化？ 原因1：数据安全 - Redis宕机、服务器断电、进程被杀 - 内存数据丢失 - 持久化后可以恢复 原因2：快速恢复 - 没有持久化：需要从数据库重新加载（10分钟+） - 有持久化：直接加载持久化文件（1分钟） 原因3：数据备份 - 定期备份持久化文件 - 灾难恢复（机房火灾、磁盘损坏） Redis的两种持久化方式： ...

一、引子：Redis宕机后数据去哪了？ Redis是内存数据库，数据存储在内存中。那么问题来了：Redis宕机后，数据还在吗？ 1.1 场景：双11大促数据丢失事故 场景：电商网站，双11大促 00:00:00 - 大促开始，流量暴增 00:00:01 - Redis缓存：10万个商品详情、50万个用户Session 00:05:00 - 服务器断电（机房故障） 00:05:01 - Redis进程被杀，内存数据全部丢失 00:10:00 - 服务器恢复，Redis重启 00:10:01 - Redis启动成功，但数据为空！ 问题： 1. 所有商品详情缓存丢失 → 10万次数据库查询 2. 所有用户Session丢失 → 50万用户被强制登出 3. 缓存预热需要10分钟 → 数据库压力巨大 4. 用户体验极差 → 大量用户流失 损失： - 用户流失：50万用户 × 10% = 5万用户 - 订单损失：5万用户 × 20% = 1万单 - GMV损失：1万单 × 200元 = 200万元 核心问题：Redis是内存数据库，断电后数据丢失，需要持久化。 1.2 持久化的本质 持久化：将内存中的数据保存到磁盘，重启后可以恢复。 为什么需要持久化？ 原因1：数据安全 - Redis宕机、服务器断电、进程被杀 - 内存数据丢失 - 持久化后可以恢复 原因2：快速恢复 - 没有持久化：需要从数据库重新加载（10分钟+） - 有持久化：直接加载持久化文件（1分钟） 原因3：数据备份 - 定期备份持久化文件 - 灾难恢复（机房火灾、磁盘损坏） Redis的两种持久化方式： ...

引言 上一篇我们学习了RDB快照，但它有一个缺点：两次快照之间的数据可能丢失。 如果你的业务对数据安全性要求很高（比如交易系统、订单系统），RDB就不够了。这时候需要AOF（Append Only File）。 AOF的核心思想：记录每一条写命令，恢复时重新执行。 RDB：拍照存档（快但可能丢数据） AOF：录像回放（慢但更安全） 一、AOF的本质 1.1 什么是AOF？ AOF是命令日志（Command Log）： Redis执行写命令 ↓ 记录命令到AOF文件（appendonly.aof） ↓ 服务器重启时 ↓ 重新执行AOF文件中的所有命令 ↓ 恢复数据 示例： # Redis执行的命令 127.0.0.1:6379> SET name "张三" OK 127.0.0.1:6379> SADD tags "Java" "Redis" (integer) 2 127.0.0.1:6379> ZADD rank 100 "user1" (integer) 1 # AOF文件内容（RESP协议格式） *2 $6 SELECT $1 0 *3 $3 SET $4 name $6 张三 *4 $4 SADD $4 tags $4 Java $5 Redis *4 $4 ZADD $4 rank $3 100 $5 user1 1.2 AOF配置 redis.conf： ...