Why Running KEYS * on Redis Can Crash Your System – Lessons from a Real‑World Outage

1. News

A PHP engineer executed keys * wxdb…cf8* on a production Redis instance, which locked Redis, caused CPU to spike, and stalled all payment‑related requests. After about ten seconds the traffic was redirected to the RDS database, leading to a cache avalanche and a full database crash, resulting in a loss of 4 million yuan.

2. A Strict Rule

In Redis operational standards, it is strictly prohibited to use the KEYS command with pattern matching in production environments.

3. Root Cause Analysis

Redis is single‑threaded; all operations are atomic, but using high‑cost commands like KEYS consumes the sole thread, blocking all other requests. When QPS is high, thousands of read/write requests hang, CPU usage skyrockets, the Redis server crashes, and the sudden surge of requests to the underlying database causes it to fail as well.

Operations staff ran keys *, a time‑consuming command that locked Redis.

High QPS caused many requests to hang on the locked Redis.

CPU usage surged, leading to Redis server failure.

All pending requests fell back to the database, causing a database outage.

4. Other Dangerous Commands

Besides keys *, other O(N) commands can also cause similar problems. The following image lists typical risky commands:

5. Disabling Risky Commands

Add the following entries to the SECURITY section of redis.conf to disable them:

For the FLUSHALL command, set appendonly no in the configuration; otherwise the server cannot start.

6. Improvement Recommendations

Instead of KEYS or other O(N) commands, use the SCAN command (available since Redis 2.8) to iterate over keys in batches. Although it increases total query time, it prevents the Redis instance from becoming unresponsive.

For detailed usage, refer to the official documentation: http://doc.redisfans.com/key/scan.html