Master Redis: 13 Proven Practices to Boost Memory, Performance & Reliability

Hello, I'm Kaito. This article shares Redis best‑practice guidance.

Typical problems you may encounter include rapid memory growth, increasing operation latency, frequent failures, operational pitfalls, resource‑planning challenges, and unclear monitoring metrics.

How to Save Redis Memory?

Redis stores data in memory, so efficient memory use is critical. Key recommendations:

Control key length : Keep keys short (e.g., u:bk:123 instead of user:book:123).

Avoid big keys : Keep String values under 10 KB and collection elements under 10 k items.

Choose appropriate data types : Use Redis’s internal encodings (integer, ziplist, etc.) to reduce memory.

Use Redis as a cache : Set expiration times and let the database be the source of truth.

Set maxmemory and eviction policy : Choose policies such as volatile-lru, allkeys-lru, volatile-lfu, allkeys-lfu, volatile-ttl, or volatile-random based on workload.

Compress data before writing : Apply algorithms like Snappy or gzip, balancing CPU cost.

How to Keep Redis Performing at High Speed?

Key performance tips (13 items):

Avoid storing big keys – they increase memory use and latency.

Enable lazy‑free (Redis 4.0+) to off‑load large deletions to background threads.

Steer clear of high‑complexity commands (e.g., SORT, SINTER, ZUNIONSTORE) or move aggregation logic to the client.

When using O(N) commands, first check the collection size; fetch data in batches if large.

Be aware of DEL complexity – it is O(1) for strings but O(N) for collections; delete large collections in batches.

Use batch commands ( MGET/MSET, HMGET/HMSET) or pipelines to reduce round‑trips.

Avoid concentrating expired keys; spread expirations to prevent blocking.

Prefer long‑lived connections and a properly sized connection pool.

Use only db0 – simplifies clustering and avoids extra SELECT overhead.

Deploy read‑write splitting and sharding clusters for heavy read/write workloads.

Disable AOF or set appendfsync everysec to limit disk I/O.

Run Redis on physical machines to avoid fork overhead on virtualized hosts.

Turn off OS huge‑page memory allocation to prevent latency spikes during copy‑on‑write.

How to Ensure Redis Reliability?

Deploy instances per business line for resource isolation.

Use master‑slave clusters to avoid single‑point failures.

Configure replication parameters (e.g., repl-backlog, slave‑client‑output‑buffer‑limit) wisely.

Deploy Sentinel for automatic failover with an odd number of nodes.

Daily Redis Operations Checklist

Prohibit KEYS, FLUSHALL, FLUSHDB – they block the main thread; replace with SCAN or async flushes.

When scanning, add sleep intervals to avoid OPS spikes.

Use MONITOR sparingly; it can consume memory on busy instances.

Set slaves to slave‑read‑only to prevent write divergence.

Configure reasonable timeout and enable tcp‑keepalive to clean up dead client connections.

When adjusting maxmemory, modify slaves before masters for increases and masters before slaves for decreases.

How to Secure Redis?

Never expose Redis directly to the public internet.

Change the default port (6379).

Run Redis under a non‑root user.

Restrict file‑system permissions of configuration files.

Enable password authentication.

Rename or disable dangerous commands such as KEYS, FLUSHALL, CONFIG, EVAL.

Prevention Strategies

Two pillars: proper resource planning and comprehensive monitoring.

Ensure sufficient CPU, memory, bandwidth, and disk; reserve half of the machine’s memory for the master; keep single‑instance memory under 10 GB.

Monitor CPU, memory, network, disk, slowlog, expired_keys, evicted_keys, and latest_fork_usec; set alerts for abnormal spikes.

By following these guidelines, developers and DBAs can efficiently use Redis while maintaining performance, reliability, and security.