Redis中dict_force_resize_ratio默认值为5的原因（含dict.c相关疑问）

Great question! Let's break down the reasoning behind this default value and the related design choices in dict.c.

First, what does dict_force_resize_ratio do? #

Redis uses progressive rehashing for its hash tables (the underlying structure for dictionaries like the keyspace, hash types, etc.) to avoid blocking the event loop during resizing. Normally, rehash starts when the load factor (number of used slots / total slots) exceeds 1. But if write traffic is so high that progressive rehash can't keep up, the load factor keeps climbing. That's where dict_force_resize_ratio comes in: when the load factor hits 5, Redis stops the gradual rehash and forces a blocking, full rehash to get the hash table back to a healthy state.

Why 5 specifically? #

The value 5 is a carefully chosen balance between two competing priorities:

• Avoiding unnecessary blocking: Progressive rehash is designed to keep Redis responsive, so we don't want to trigger a forced resize too early. A lower threshold (like 2) might cause frequent blocking during traffic spikes, hurting stability.
• Preventing performance degradation: As the load factor rises, hash collisions increase, turning O(1) operations into O(n) as we traverse longer linked lists. A threshold of 5 gives progressive rehash enough time to catch up during lulls in traffic, but not so high that the hash table becomes a performance bottleneck. Redis's core team arrived at this number through real-world testing and production experience.

Design details in dict.c #

Looking at the code in dict.c, the logic lives in the dictExpandIfNeeded function:

• When a hash table is already in progressive rehash (i.e., ht[1] exists), Redis checks if the load factor of the old table (ht[0]) exceeds dict_force_resize_ratio.
• If it does, Redis calls dictRehash with a large number of steps (or even completes the entire rehash in one go) instead of the usual small, incremental steps.
• This design prioritizes responsiveness first, but acts as a safety net: it recognizes that when the load factor hits 5, the performance cost of letting the hash table stay in that state is worse than the temporary blocking from a forced resize.

For example: If Redis is under a sustained high write load, progressive rehash might not keep pace with new entries. Once the load factor hits 5, the hash table's operations would start to slow down drastically. Forcing a full rehash here is a short-term pain for long-term gain—blocking briefly to restore O(1) performance across all hash table operations.

内容的提问来源于stack exchange，提问作者Artikell