Redis之所以能在内存数据库中保持高效的键值查询，很大程度上依赖哈希表结构与配套的rehash机制。当哈希表需要扩容或缩容时，Redis并不会一次性迁移所有数据，而是采用渐进式rehash策略分步完成，避免阻塞服务。activerehashing这个配置项正是控制Redis是否在后台主动执行这些迁移步骤的开关。理解它的工作方式，有助于在内存使用、延迟表现和CPU消耗之间做出合理取舍。
一、activerehashing到底控制哪个过程
Redis的键值对存储基于哈希表实现，每个数据库实例包含两个哈希表，分别用于存储实际数据和渐进式迁移。当哈希表负载因子超过阈值时，Redis会分配一个更大的哈希表，并将旧表数据逐步搬移过去，这个过程称为rehash。activerehashing开关控制的并不是rehash本身是否执行，而是Redis是否在后台定时任务中主动推进这次数据搬迁。
从配置层面看，redis.conf中的activerehashing默认值为yes。打开这个开关后，Redis的serverCron定时任务每次执行时会根据当前实例的空闲程度，调用incrementallyRehash函数处理一定数量的哈希桶。如果关闭该开关，Redis仍然会在每次对哈希表进行读写操作时顺带迁移一个桶，也就是所谓的惰性rehash。两者的区别在于：主动模式下即使没有客户端请求，rehash也会继续；惰性模式下则完全依赖访问触发。
以实际运行效果为例，假设一个包含数百万键的大字典触发了扩容，如果此时业务请求量突然下降，关闭activerehashing的实例可能很长时间停留在旧表与新表并存的阶段，内存占用明显高于实际数据量。而开启主动rehash的实例会在后台逐步完成迁移，旧表很快被释放。因此这个开关对内存峰值和延迟毛刺有直接影响。
二、源码中的主动rehash是如何实现的
在Redis源码的serverCron函数中，可以看到一段与activerehashing相关的逻辑。serverCron大约每100毫秒执行一次，它首先判断配置项activerehashing是否为1，如果开启，则遍历当前数据库，调用dictRehashMilliseconds函数，在指定的时间片内对字典进行rehash。
dictRehashMilliseconds函数接收一个字典指针和一个毫秒数参数，它将当前时间记录下来，然后循环调用dictRehash函数，每次处理固定数量的哈希桶。dictRehash函数内部会检查是否处于rehash状态，然后最多迁移若干个非空桶到新表。每处理完一批，函数会检查已经消耗的时间，如果超过分配的时间片就立即返回，避免阻塞整个事件循环。
这里可以给出一段简化的定时任务代码逻辑，便于理解主动rehash的时间片控制：
void serverCron(void) {
// 其他定时任务...
if (server.activerehashing) {
for (int j = 0; j < server.dbnum; j++) {
// 每次给每个库分配1毫秒做主动rehash
dictRehashMilliseconds(server.db[j].dict, 1);
dictRehashMilliseconds(server.db[j].expires, 1);
}
}
// 其他逻辑...
}
实际上Redis还会根据数据库的忙闲状态调整时间片，例如在流量高峰时减少主动rehash的耗时，保证请求响应优先。这一机制避免为了尽快完成迁移而挤占正常命令处理时间。
三、开启与关闭的实测差异及配置建议
为了更直观地观察activerehashing的影响，可以在测试环境运行一个键数量达到百万级别的Redis实例，并设置较高的哈希表负载因子。先关闭activerehashing，写入大量数据触发扩容，然后停止请求，通过INFO命令查看used_memory和哈希表相关统计。此时会发现used_memory长期维持在高位，因为旧哈希表还没有释放。再打开activerehashing，等待几十秒后重新查看，内存占用会明显下降。
从延迟角度看，主动rehash通常不会造成明显卡顿，因为每次只占用1毫秒左右的时间片。但如果实例的CPU本身已经接近饱和，频繁的主动rehash可能让一些命令出现细微排队。此时如果业务对延迟极度敏感，并且键数量规模较小，可以考虑关闭activerehashing，让rehash只随命令触发。不过大多数情况下，默认开启是更稳妥的选择。
配置方式有两种：一是在redis.conf中写入activerehashing yes或activerehashing no，重启后生效；二是在运行期使用CONFIG SET activerehashing no动态调整。例如：
redis-cli CONFIG SET activerehashing no redis-cli CONFIG SET activerehashing yes
动态修改不会中断服务，适合临时评估影响。需要特别注意的是，activerehashing仅影响主库字典的主动迁移，即使关闭它，expires字典同样受此开关控制。因此在有大量过期键的场景下，关闭开关也可能导致过期字典迁移停滞，进而影响过期键的回收效率。
此外，如果使用Redis集群或哨兵，各个节点的配置应保持一致，避免主从切换后出现行为差异。对于写多读少、数据量巨大的缓存节点，建议保持activerehashing开启；而对于数据量小、CPU资源紧张且延迟要求极高的场景，可以结合监控数据决定是否关闭。
四、容易混淆的几个问题
第一个容易混淆的点是把activerehashing理解为rehash的总开关。实际即使activerehashing设为no，字典扩容、缩容和渐进式rehash依然会执行，只不过迁移由访问驱动的惰性rehash完成。第二个误解是认为开启activerehashing能让所有大key的迁移瞬间结束。这是错误的，因为时间片限制和键本身的大小决定了迁移速度，大value在迁移时仍然可能带来瞬时阻塞。
第三个误区是只关注内存而忽略CPU。主动rehash虽然能更快释放旧表，但它消耗的是后台任务的计算资源。在一些低配云主机或共享CPU环境中，如果服务器已经存在明显CPU争抢，开启主动rehash可能使性能抖动更频繁。此时应该通过redis-benchmark和延迟监控来确定瓶颈来源，而不是直接修改开关。
最后，还有一种常见观点认为从节点不需要关注activerehashing。实际上从节点也会处理数据写入，其字典同样需要rehash。虽然主从同步通过命令流更新从库，但触发条件和主库类似。保持主从配置一致可以减少切换后的不确定性。
Redis activerehashing主动rehash哈希表扩容修改时间：2026-09-23 14:19:40