Mastering Redis: Core Data Structures, Commands, and Performance Tuning

This article introduces Redis basics, its data structures and main commands, and then provides deeper guidance on performance tuning, replication, and clustering.

Overview

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

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

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

All operations run on a single thread using non‑blocking I/O, which makes Redis thread‑safe and extremely fast, but also means long‑running commands can block the entire server.

Redis is thread‑safe because only one thread handles all client requests. Its non‑blocking I/O and O(1) command complexities give it very high throughput. Using high‑cost commands (e.g., KEYS with O(N) complexity) is dangerous in production.

Redis Data Structures and Common Commands

Key

Keys can be any binary sequence. Best practices include avoiding overly long keys, using readable naming conventions (e.g., object-type:id:attr), and keeping keys under 512 MB.

String

Strings are the fundamental data type. Common commands:

SET key value [EX|PX] [NX|XX] – O(1) GET key – O(1) GETSET key value – O(1) MSET key1 value1 ... – O(N) MSETNX key1 value1 ... – O(N) MGET key1 key2 ... – O(N)

Strings can also be used as integers or floats for atomic increment/decrement operations:

INCR key – O(1) INCRBY key increment – O(1) DECR key / DECRBY key decrement – O(1)

Example 1 – Inventory control:

SET inv:remain "100"
DECR inv:remain

Example 2 – Auto‑incrementing sequence:

SET sequence "10000"
INCR sequence
INCRBY sequence 100

List

Lists are linked‑list structures suitable for queue semantics. Common commands:

LPUSH key element [element ...] – O(N) (N = number of elements pushed) RPUSH key element [element ...] – O(N) LPOP key – O(1) RPOP key – O(1) LLEN key – O(1) LRANGE key start stop – O(N) (N = number of returned elements)

Commands such as LINDEX, LSET, and LINSERT have O(N) complexity and should be used cautiously on large lists.

Hash

Hashes map fields to values, similar to a hashmap. Common commands:

HSET key field value – O(1) HGET key field – O(1) HMSET/HMGET key field1 value1 ... – O(N) HSETNX key field value – O(1) HEXISTS key field – O(1) HDEL key field [field ...] – O(N) HINCRBY key field increment – O(1)

Full scans with HGETALL, HKEYS, or HVALS are O(N) and should be replaced by HSCAN for large hashes.

Set

Sets are unordered collections of unique strings. Common commands:

SADD key member [member ...] – O(N) SREM key member [member ...] – O(N) SRANDMEMBER key [count] – O(N) SPOP key [count] – O(N) SCARD key – O(1) SISMEMBER key member – O(1) SMOVE source destination member – O(1)

Operations that traverse the whole set (e.g., SMEMBERS, SUNION, SINTER, SDIFF) are O(N) and should be avoided on large sets; use SSCAN instead.

Sorted Set

Sorted sets store unique strings with an associated score, enabling ranking. Common commands:

ZADD key score member [score member ...] – O(M log(N)) ZREM key member [member ...] – O(M log(N)) ZCOUNT key min max – O(log(N)) ZCARD key – O(1) ZSCORE key member – O(1) ZRANK/ZREVRANK key member – O(log(N)) ZINCRBY key increment member – O(log(N))

Range queries ( ZRANGE, ZREVRANGE, ZRANGEBYSCORE, ZREVRANGEBYSCORE) and deletions ( ZREMRANGEBYRANK, ZREMRANGEBYSCORE) should avoid full scans (e.g., 0 -1) on unknown‑size sets; use LIMIT or ZSCAN instead.

Bitmap and HyperLogLog

Bitmaps treat strings as bit arrays for space‑efficient true/false storage. HyperLogLog provides approximate cardinality counting with far lower memory usage than a full set.

Other Common Commands

EXISTS key – O(1) DEL key [key ...] – O(N) EXPIRE/PEXPIRE key seconds|milliseconds – O(1) TTL/PTTL key – O(1) RENAME/RENAMENX key newkey – O(1) TYPE key – O(1) CONFIG GET pattern – O(1) CONFIG SET parameter value – O(1) CONFIG REWRITE – reloads configuration file

Redis Performance Tuning

Even though Redis is fast, performance issues can arise because all commands share a single thread.

Avoid long‑running commands. Use pipelining to batch commands. Disable Transparent Huge Pages: <code>echo never > /sys/kernel/mm/transparent_hugepage/enabled</code> Prefer physical machines over VMs for latency‑sensitive workloads. Review persistence settings. Consider read‑write splitting.

Long‑Running Commands

Most commands are O(1)–O(N). Commands with O(N) complexity should be avoided when the data size is unpredictable (e.g., HGETALL, KEYS, SUNION, SORT).

Do not use KEYS in production. Prefer SCAN , SSCAN , HSCAN , ZSCAN for incremental iteration.

Network‑Induced Latency

Use persistent connections or connection pools. Batch operations with pipelines.

Persistence‑Induced Latency

AOF with fsync always guarantees durability but hurts performance; fsync everysec is a common compromise. Forking for RDB snapshots or AOF rewrites can pause the server; monitor latest_fork_usec via INFO.

Swap‑Induced Latency

If Redis memory is swapped out, the process blocks. Avoid memory pressure and heavy I/O to prevent swapping.

Eviction‑Induced Latency

Mass expirations in the same second can cause latency spikes; stagger key TTLs when possible.

Read/Write Splitting

Use replica slaves for read‑only or low‑latency‑requirement queries, especially for heavy analytical tasks.

Master‑Slave Replication and Cluster Sharding

Master‑Slave Replication

Redis supports one‑master‑multiple‑slaves replication. Writes go to the master; slaves replicate data and can serve reads.

Read‑only workloads can be offloaded to slaves. Redis Sentinel provides automatic failover.

Configure a slave with:

slaveof 192.168.1.1 6379

Sentinel Automatic Failover

Sentinel monitors masters, elects a new master on failure, and updates configuration.

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

Cluster Sharding

When a single node cannot hold all data or handle write load, sharding distributes data across multiple nodes.

Redis Cluster (introduced in 3.0) automatically splits data into 16384 hash slots; each key’s CRC16 modulo 16384 determines its slot.

Clients can connect to any node; the cluster redirects requests to the correct slot.

Hash Tags

Keys containing a substring in braces (e.g., {user}id:1000) are forced into the same slot, enabling multi‑key operations like pipelines, transactions, or Lua scripts within a single shard.

Master‑Slave vs. Cluster

Cluster solves data‑size and write‑throughput limits and includes replication, but adds operational complexity, higher client resource consumption, and stricter constraints on transactions and scripts.

Choose master‑slave when a single node meets memory and performance needs and when heavy use of pipelines or transactions would complicate a clustered design.

Assess data volume, growth expectations, available memory, and write concurrency before deciding to adopt sharding.