Mastering Redis: Data Structures, Commands, and Performance Tuning

Overview

Redis is an open‑source, in‑memory data store that can serve as a database, cache, or message broker.

It supports multiple data structures such as strings, hashes, lists, sets, sorted sets, bitmaps, and HyperLogLog.

Redis offers LRU eviction, transactions, various persistence levels, replication, high‑availability via Sentinel, and automatic sharding with Redis Cluster.

Redis is thread‑safe because it runs a single thread, making all operations atomic. Its non‑blocking I/O and O(1) command complexities give it very high speed. Long‑running commands (e.g., O(N) commands like KEYS ) can block the single thread and degrade performance.

Redis Data Structures and Common Commands

This section introduces the main data structures and frequently used commands. For a complete command reference, see the official documentation.

Key

Keys can be any binary string. Best practices include using a consistent naming convention (e.g.,

object-type:id:attr

) and avoiding overly long or overly short keys. Maximum key length is 512 MB.

String

Strings are the basic type; integers and floats are stored as strings. Common commands include

SET

,

GET

,

GETSET

,

MSET

,

MSETNX

,

MGET

. Increment/decrement commands (

INCR

,

DECR

, etc.) operate on numeric strings.

Example 1: Inventory control using SET inv:remain "100" and DECR inv:remain . Example 2: Sequence generation with SET sequence "10000" and INCR sequence (or INCRBY sequence 100 for batches).

List

Lists are linked‑list structures. Commands include

LPUSH

,

RPUSH

,

LPOP

,

RPOP

,

LPUSHX

,

RPUSHX

,

LLEN

,

LRANGE

. Use lists primarily as queues; avoid treating them as general arrays.

Avoid O(N) commands like LINDEX , LSET , LINSERT on large lists.

Hash

Hashes map fields to values, similar to a hashmap. Useful for representing objects. Common commands:

HSET

,

HGET

,

HMSET

,

HMGET

,

HSETNX

,

HEXISTS

,

HDEL

,

HINCRBY

. Avoid full scans with

HGETALL

,

HKEYS

,

HVALS

on large hashes; use

HSCAN

instead.

Set

Sets are unordered collections of unique strings. Commands:

SADD

,

SREM

,

SRANDMEMBER

,

SPOP

,

SCARD

,

SISMEMBER

,

SMOVE

. Avoid costly operations like

SMEMBERS

,

SUNION

,

SINTER

,

SDIFF

on large sets; prefer

SSCAN

and client‑side processing.

Sorted Set

Sorted sets store unique strings with a score for ordering. Key commands:

ZADD

,

ZREM

,

ZCOUNT

,

ZCARD

,

ZSCORE

,

ZRANK

,

ZREVRANK

,

ZINCRBY

. Use range queries (

ZRANGE

,

ZREVRANGE

,

ZRANGEBYSCORE

) with limits to avoid full scans.

Bitmap and HyperLogLog

Bitmaps treat strings as bit arrays for compact true/false storage. HyperLogLog provides approximate cardinality counting with low memory overhead.

Redis Performance Tuning

Even though Redis is fast, performance issues can arise due to its single‑threaded model.

Avoid long‑running commands. Use pipelining to batch commands. Disable Transparent Huge Pages (THP) on the OS. Prefer physical machines over VMs for latency‑sensitive workloads. Review persistence settings (AOF vs RDB) and their impact. Consider read‑write separation.

Long‑Running Commands

Most commands are O(1) to O(N). Use O(N) commands cautiously, especially when the data size is unpredictable. Never use

KEYS

; prefer

SCAN

and its variants.

Network‑Induced Latency

Use persistent connections or connection pools. Leverage pipelining for bulk operations.

Persistence‑Induced Latency

AOF with

fsync always

guarantees durability but hurts performance;

fsync every second

is a common compromise. Forking for RDB snapshots or AOF rewrites can cause noticeable pauses.

Swap‑Induced Latency

When Redis memory is swapped out, latency spikes occur. Ensure sufficient RAM to avoid swapping.

Expiration‑Induced Latency

Mass expirations in a short time can cause delays; stagger key TTLs.

Replication and Cluster Sharding

Master‑Slave Replication

One master handles writes; slaves replicate data and can serve reads, improving scalability and providing high availability when combined with Sentinel.

Sentinel for Automatic Failover

Sentinel monitors masters, detects failures, and promotes a slave to master. At least three Sentinel instances are recommended for quorum.

Cluster Sharding

Redis Cluster distributes data across 16384 hash slots, automatically routing requests to the correct node. It provides horizontal scaling and fault tolerance.

Automatic data distribution. Request redirection to the correct shard. Continued service when some nodes fail.

Hash tags (e.g.,

{tag}key

) ensure multiple keys reside in the same slot, which is required for pipelining, transactions, and Lua scripts in a cluster.

Choosing Between Replication and Cluster

Evaluate data size, write concurrency, and operational complexity. If a single node can handle memory and load, master‑slave replication is simpler. If data exceeds a single node’s capacity or write pressure is high, consider Redis Cluster, acknowledging its added operational overhead.

Redis Java Client Selection

Popular clients: Jedis, Redisson, Lettuce.

Jedis – lightweight, supports connection pooling, pipelining, transactions, Lua scripting, Sentinel, and Cluster, but lacks built‑in read‑write splitting and has sparse documentation.

Redisson – Netty‑based, asynchronous, high performance, supports connection pooling, pipelining, Lua scripting, Sentinel, Cluster, read‑write splitting, and provides additional features like Tomcat session management and Spring Session integration.

Choose Jedis for simple use‑cases; opt for Redisson when advanced features such as read‑write separation or asynchronous operations are required.