Database / REDIS
Explain the internal working of Redis's hash table resizing (rehashing)?
Redis's core keyspace (and large Hash-type values) are backed by a hash table, and as entries are added or removed, the table needs to grow or shrink to keep lookups close to O(1) — but a naive full rehash (allocate a new table, move every entry, free the old one) would briefly block every other operation on a table with millions of entries, which conflicts directly with Redis's single-threaded, low-latency design.
This incremental rehashing spreads the cost of a full table resize across many individual commands instead of pausing everything for one large operation, which is what lets Redis resize its hash tables even under heavy load without a noticeable latency spike. During the migration window, any lookup for a key has to check both tables (since it might not have been migrated yet), which is a small, bounded per-operation cost rather than one large blocking one.
More Related questions...
