10 Essential Redis Best Practices Every Engineer Should Follow

Redis has become a hot topic in the tech community, evolving from a personal project by Antirez into the industry standard for in‑memory data storage, accompanied by a set of best practices that enable most users to use Redis correctly.

1. Stop Using KEYS *

Running KEYS * may seem convenient for inspecting keys, but its O(n) time complexity makes it impractical for large datasets and blocks other commands during execution.

for key in 'keys *':
    doAllTheThings()

Instead, use SCAN, which iterates incrementally using a cursor, allowing you to pause or continue as needed.

2. Identify What Slows Down Redis

Redis lacks detailed logs, but you can use the INFO commandstats command to see statistics for each command, such as call count and execution time.

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

Reset statistics with CONFIG RESETSTAT to obtain a fresh snapshot.

3. Use Redis‑Benchmark Results as Reference, Not Absolute Truth

Benchmark results depend on client environment, Redis version, and similarity between test and production environments. Treat them as a baseline, not a definitive stress test.

Are there client‑side limitations?

Is the version the same?

Does the test environment match production?

4. Prefer Hashes Over Multiple Keys

Instead of storing related fields as separate keys (e.g., foo:first_name, foo:last_name), use a hash to keep all fields under a single key.

127.0.0.1:6379> HSET foo first_name 'Joe'
(integer) 1
127.0.0.1:6379> HSET foo last_name 'Engel'
(integer) 1
127.0.0.1:6379> HSET foo address '1 Fanatical Pl'
(integer) 1
127.0.0.1:6379> HGETALL foo
1) 'first_name'
2) 'Joe'
3) 'last_name'
4) 'Engel'
5) 'address'
6) '1 Fanatical Pl'

5. Set Expiration for Keys When Possible

Leverage key expiration for temporary data such as authentication tokens, allowing Redis to automatically remove them without manual scanning.

6. Choose an Appropriate Eviction Policy

When memory fills up, Redis evicts keys based on the selected policy. For keys with expiration, volatile‑lru is recommended; for cache‑like data without expiration, consider allkeys‑lru.

7. Protect Critical Data with Try/Except

Wrap important write operations in try/except blocks to ensure data is actually stored, as many Redis clients use a fire‑and‑forget approach.

8. Distribute Load Across Multiple Instances

Use Redis Cluster (available since 3.0.0) to shard data by key range, or employ namespaces and multiple instances to avoid overloading a single node.

9. More Cores Do Not Mean Better Performance

Redis is single‑threaded; even with persistence enabled it uses at most two cores. Running multiple instances on one machine is only advisable for testing.

10. Ensure High Availability

Redis Sentinel provides robust high‑availability solutions used in production by many users. If you prefer a managed service, consider providers that offer 24/7 support.

Source: https://www.cnblogs.com/zhuifeng523/p/12274740.html