Understanding and Mitigating Bigkey Issues in Redis Operations

During Redis operation, the presence of Bigkey can degrade response speed and even cause availability loss. DBAs have been urging developers to avoid Bigkey, but it still appears across a massive fleet of over 2,200 Redis clusters and more than 45,000 instances.

Background : A full‑network Bigkey inspection would take years, so a new approach is needed.

What is a Bigkey? In Redis, a string value larger than 1 MB or a non‑string data structure (hash, list, set, zset) with more than 2,000 elements is considered a Bigkey.

How Bigkeys are generated :

Statistics: keys that accumulate IP addresses of website visitors over time.

Cache: bulk data serialized into Redis and repeatedly appended.

Queue: using Redis as a queue where slow consumption lets the queue grow.

Risks of Bigkeys :

Uneven memory usage – large keys can occupy several gigabytes, causing memory imbalance across cluster nodes.

Timeout blocking – Redis processes commands single‑threaded; a Bigkey operation can block other commands, leading to client timeouts and even master‑slave failover. Example: an hkeys command took >500 ms due to a hash‑type Bigkey.

Network congestion – a 10 MB Bigkey accessed 100 times per second generates ~1 GB/s traffic, overwhelming a 1 Gbps network.

Migration difficulty – during horizontal scaling, migrate (implemented as dump + restore + del ) blocks both source and target nodes. A Bigkey can cause migration to exceed its timeout, leading to failed scaling operations.

Detection methods :

--Bigkeys (Redis 4.0+): returns the top‑1 Bigkey per data type. Recommended to run on a slave to avoid blocking.

RDB file analysis using tools like rdb-tools to scan stored snapshots for oversized keys.

Inspection and optimization :

Perform cluster‑wide Bigkey inspections by analyzing all slave nodes in parallel (default concurrency = 10).

When a Bigkey is found, split it: break large lists into list1, list2, … , re‑hash large hashes (e.g., hash%100 ), or partition by date (e.g., key20220310 ).

Adjust migration parameters: set cluster-node-timeout to 15 minutes before migration, limit migrate timeout to 10 s per retry with 30 s intervals, and cap retries to three attempts. Record detailed logs (node, slot, key) for quick diagnosis.

Conclusion : Effective Bigkey management requires proactive prevention, timely detection, and optimized handling during scaling. By improving inspection tools, refining migration settings, and educating developers, the impact of Bigkeys on Redis performance and availability can be substantially reduced.