Redis 7.2.x 内存碎片整理功能缺陷分析与修复

Redis作为一款高性能的内存数据库，其内存管理机制一直是开发者关注的重点。在Redis 7.2.x版本中，内存碎片整理功能(active defragmentation)被发现存在一个可能导致服务崩溃的严重缺陷。本文将深入分析这个问题的成因、影响范围以及修复方案。

问题背景

Redis的内存碎片整理功能通过activeDefragCycle函数周期性执行，旨在优化内存使用效率。该功能可以在运行时动态启用或禁用，通过CONFIG SET activedefrag命令进行控制。

问题现象

当Redis运行在集群模式下，并且满足以下条件时会出现崩溃：

1. 数据库加载了大量带有随机短TTL的简单字符串键
2. 在碎片整理过程中执行了先禁用再重新启用碎片整理功能的操作

崩溃发生时，错误表现为非法内存访问(SIGSEGV)，访问地址为0x48，这表明程序尝试解引用一个空指针或无效指针。

根本原因分析

通过分析崩溃堆栈和代码，发现问题出在defragLaterStep函数中。当碎片整理功能被临时禁用又立即重新启用时，内部的expires_counter状态变量没有被正确重置。

具体来说：

1. 在activeDefragCycle函数中，当检测到碎片整理被禁用时，会跳过主要处理逻辑
2. 但是跳过时没有重置expires_counter计数器
3. 当重新启用后，程序继续使用这个无效的计数器值，导致后续处理中出现空指针解引用

影响范围

该问题影响Redis 7.2.x系列版本，特别是在以下场景中：

• 运行在集群模式下
• 启用了内存碎片整理功能
• 存在大量带有过期时间的键
• 在运行过程中动态调整碎片整理配置

修复方案

修复方案的核心是在碎片整理功能被临时禁用时，正确重置所有相关的状态变量。具体修改包括：

1. 在activeDefragCycle函数中添加对expires_counter的重置逻辑
2. 确保状态一致性，避免使用无效的计数器值

修复后的代码保证了即使碎片整理功能被临时禁用又启用，也能安全地继续执行而不会崩溃。

技术启示

这个案例给我们带来几点重要的技术启示：

1. 状态机设计：对于周期性执行且可动态启停的功能，必须仔细设计状态转换逻辑
2. 防御性编程：在可能被动态修改的配置项相关代码中，需要加入更多的完整性检查
3. 测试覆盖：需要增加对配置动态修改场景的测试用例，特别是启停类操作

总结

Redis内存碎片整理功能的这个缺陷展示了即使是成熟的开源项目，在复杂的状态管理场景下也可能出现边界条件问题。通过深入分析崩溃原因并实施针对性的修复，不仅解决了具体的崩溃问题，也为类似功能的设计提供了有价值的参考。