Redis 为什么不会每次修改都写磁盘上一篇我们聊了《Redis 为什么要同时支持 RDB 和 AOF》了解了 Redis 在持久化设计上的取舍。RDB 通过保存某个时间点的数据快照让 Redis 可以快速恢复数据但是两次快照之间的数据可能丢失。AOF 通过记录每一次写操作让 Redis 尽可能减少数据丢失但是随着运行时间增加日志文件会越来越大。所以 Redis 最终选择了两种方案结合。但是 AOF 又带来了一个新的问题既然 AOF 可以记录每一次修改那为什么 Redis 不直接在每一次修改之后把数据同步到磁盘这样不是最安全的吗例如客户端执行 SET↓修改内存数据↓写入 AOF↓同步磁盘↓返回成功如果按照这个流程执行Redis 返回成功时数据已经真正保存到了磁盘。看起来这是一个完美方案。但是 Redis 并没有这么设计。原因是Redis 追求的并不是绝对的数据安全而是在接近内存速度的情况下提供足够可靠的数据恢复能力。如果每一次修改都等待磁盘完成Redis 最核心的优势反而会消失。Redis 为什么不能每次修改都写磁盘Redis 快的原因大家通常会想到“因为 Redis 使用内存。”这个答案没有错但是不完整。真正决定 Redis 性能的是它的大部分操作都发生在内存中。例如执行SET user:name redisRedis 需要做的事情非常简单接收命令↓解析命令↓修改内存数据结构↓返回结果整个过程没有磁盘参与。但是如果增加持久化接收命令↓修改内存数据结构↓写入磁盘↓等待磁盘完成↓返回结果问题就出现了。内存和磁盘的速度差距非常大。CPU 访问内存可能只需要几十纳秒而一次磁盘 IO即使 SSD也需要微秒甚至更长时间。如果 Redis 每执行一次写操作都必须等待磁盘完成那么 Redis 的性能上限就不再由 CPU 和内存决定而是由磁盘决定。对于一个追求高并发的内存数据库来说这是无法接受的。那为什么不用 write 代替磁盘同步很多人可能会想到既然同步磁盘太慢那只写文件不等待不就行了吗实际上Redis 的 AOF 写入确实不会每次都直接等待磁盘。因为 Linux 文件写入本身也有缓存机制。整个过程大致如下Redis|| write()↓操作系统 Page Cache|| fsync()↓磁盘Redis 调用 write 后数据首先进入操作系统缓存。例如write(fd, buffer, size);这个操作只是把数据交给操作系统。此时数据并不一定已经保存到了磁盘。如果机器突然断电Redis 内存↓丢失操作系统缓存↓可能丢失磁盘已保存数据↓保留所以真正保证数据落盘需要fsync(fd);fsync 会要求操作系统把缓存中的数据同步到磁盘。因此write 解决的是“写入文件”。fsync 解决的是“真正保存”。fsync 为什么不能频繁执行既然 fsync 才安全那 Redis 为什么不每次执行因为 fsync 太慢。假设 Redis 每秒处理 10 万次写请求。如果每次请求write()fsync()那么意味着磁盘需要每秒完成大量同步写操作。更严重的是fsync 会阻塞当前线程。Redis 早期核心命令执行模型是单线程客户端请求↓Redis 主线程↓执行命令↓返回结果如果加入客户端请求↓Redis 主线程↓执行命令↓等待 fsync↓返回结果那么一个磁盘慢操作就会阻塞整个 Redis。这也是 Redis 设计中非常重要的一点Redis 可以接受后台任务慢但不能接受主线程慢。因为主线程负责处理所有客户端请求。Redis 如何解决这个问题Redis 的方案是不要让写磁盘阻塞命令执行。也就是说数据修改和数据刷盘分开。客户端请求执行命令↓修改内存↓写入 AOF 缓冲区↓返回成功后台AOF 缓冲区↓后台任务↓fsync↓磁盘这样 Redis 主线程可以继续处理新的请求。这就是 Redis 持久化设计中的一个核心思想把影响性能的慢操作从核心请求链路中移出去。Redis 为什么选择 everysec既然刷盘放到了后台那么新的问题来了多久刷一次Redis 提供了三个策略appendfsync alwaysappendfsync everysecappendfsync no它们代表不同的数据安全选择。always最高安全但是牺牲性能always 表示每一次写操作都立即 fsync。流程执行命令↓写 AOF↓fsync↓返回成功这种方式数据安全最高。因为客户端收到成功响应时数据已经保存到了磁盘。但是性能最低。因为每一个请求都可能等待磁盘。对于高并发业务这种方式基本无法发挥 Redis 的优势。everysec性能和安全的平衡everysec 是 Redis 默认策略。流程客户端请求↓修改内存↓写入 AOF↓返回成功↓后台每秒 fsync它的核心思想允许极少量数据丢失换取更高性能。例如10:00:00写入数据10:00:01后台刷盘如果 Redis 在中间发生异常最多丢失最近一秒的数据。对于大部分互联网业务用户登录状态热点数据缓存信息非核心计数这种程度的数据损失通常可以接受。所以 Redis 选择不是保证每一次操作绝对安全而是保证大多数情况下数据可靠。no完全交给操作系统no 模式Redis 只负责write()什么时候同步磁盘由操作系统决定。这种方式性能最高。但是风险也最高。因为 Redis 无法控制操作系统什么时候刷盘缓存中积累了多少未保存数据所以生产环境通常不会使用。AOF Rewrite日志为什么不会无限增长解决刷盘问题之后AOF 又出现了新的问题。AOF 记录的是操作过程。例如SET count 1SET count 2SET count 3SET count 4这些命令都会保存。但是 Redis 最终状态count 4前面的SET count 1SET count 2SET count 3实际上已经没有意义。如果 Redis 长时间运行大量历史命令↓AOF 文件不断增长↓恢复时间越来越长所以 Redis 引入了AOF RewriteRewrite 并不是简单压缩文件而是根据当前内存状态重新生成 AOF。例如原来的SET count 1SET count 2SET count 3SET count 4重新生成SET count 4恢复时只需要执行最终状态。为什么 Rewrite 不会影响 Redis如果 Rewrite 在主线程执行Redis 主线程↓生成 AOF 文件↓无法处理请求这显然不可接受。所以 Redis 使用子进程完成 Rewrite。流程Redis 主进程继续处理客户端请求↓子进程生成新的 AOF↓期间新的写操作进入重写缓冲区↓合并数据↓替换旧文件Redis 再一次体现了自己的设计原则耗时操作异步化核心路径保持简单。Redis 为什么最终选择这种持久化方式如果 Redis 每次修改都立即写磁盘数据安全最高。但是性能会明显下降。如果 Redis 完全不考虑磁盘性能最高。但是数据无法恢复。所以 Redis 最终选择内存快速执行↓后台异步刷盘↓保证数据恢复能力RDB 解决的是如何快速保存某个时间点的数据。AOF 解决的是如何记录数据变化过程。everysec 解决的是如何避免磁盘影响 Redis 性能。Rewrite 解决的是如何控制 AOF 文件规模。Redis 从来没有追求一个绝对完美的方案而是在性能、可靠性和复杂度之间寻找一个工程上的平衡。这也是 Redis 能够长期保持高性能同时又具备持久化能力的原因。上一篇《Redis 为什么要同时支持 RDB 和 AOF》下一篇《Redis 为什么会发生缓存穿透、击穿、雪崩》