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

Overview

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

It supports strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLog, and provides features such as LRU eviction, transactions, persistence, replication, Sentinel high‑availability, and Cluster automatic sharding.

Redis runs on a single‑threaded event loop with non‑blocking I/O, making all operations atomic and thread‑safe.

Redis Data Structures and Common Commands

Key

Any binary sequence can be a key; keep keys short and readable, e.g., user:1000:followers. Max key size is 512 MB.

String

Basic type; commands include SET, GET, GETSET, MSET, MSETNX, MGET. Strings can be used as integers/floats for INCR, DECR, INCRBY, DECRBY (64‑bit signed range). SET inv:remain "100" – set inventory. DECR inv:remain – decrement and check for negative. SET sequence "10000" – initialize sequence. INCR sequence – get next value. INCRBY sequence 100 – reserve a block of values.

List

Linked‑list structure; commands LPUSH, RPUSH, LPOP, RPOP, LLEN, LRANGE, etc. O(N) for index‑based operations; use as queue, not as array.

Hash

Field‑value map; ideal for representing objects. Commands HSET, HGET, HMSET, HMGET, HSETNX, HEXISTS, HDEL, HINCRBY. Avoid HGETALL/HKEYS/HVALS on large hashes; use HSCAN.

Set

Unordered, unique strings. Commands SADD, SREM, SRANDMEMBER, SPOP, SCARD, SISMEMBER, SMOVE. Avoid full scans; use SSCAN for large sets.

Sorted Set

Ordered set with scores; commands ZADD, ZREM, ZCOUNT, ZCARD, ZSCORE, ZRANK, ZREVRANK, ZINCRBY, ZRANGE, ZRANGEBYSCORE, ZREMRANGEBYRANK, etc. Use ZSCAN for iteration; avoid full range queries on huge sets.

Bitmap & HyperLogLog

Bitmap uses strings as bit arrays for boolean data; HyperLogLog provides cardinality estimation with low memory.

Other Useful Commands

EXISTS, DEL, EXPIRE/PEXPIRE, TTL/PTTL, RENAME/RENAMENX, TYPE, CONFIG GET/SET/REWRITE

Redis Performance Tuning

Long‑Running Commands

Avoid O(N) commands on large collections; never use KEYS in production; prefer SCAN family for incremental iteration.

Network Latency

Use persistent connections or connection pools.

Batch operations with pipelining.

Persistence Latency

AOF with fsync always guarantees durability but hurts performance.

AOF with fsync everysec is a good compromise.

RDB snapshots are faster but less durable.

Fork operations for AOF rewrite or RDB save can pause the server; monitor latest_fork_usec.

Swap Latency

When Redis memory is swapped, latency spikes occur; avoid memory pressure and heavy I/O.

Eviction Latency

Mass expirations in the same second can cause delays; stagger TTLs.

Read/Write Splitting

Use master‑slave replication to direct reads to slaves, reducing load on the master.

Master‑Slave Replication and Sentinel

One master writes, multiple slaves replicate. Slaves can serve read‑only traffic. Sentinel monitors masters, performs automatic failover, and requires at least three instances.

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

Redis Cluster Sharding

Cluster splits data across 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 shard.

Hash tags ({tag}) force multiple keys into the same slot, required for multi‑key operations like pipelines, transactions, or Lua scripts.

Master‑Slave vs Cluster

Cluster solves single‑node memory and write‑throughput limits and includes replication, but adds operational complexity, higher client resource usage, and restrictions on transactions and scripts.

Choose replication when data size fits one node and heavy use of pipelines/transactions is needed; adopt Cluster only when sharding is truly required.

Redis Java Client Choices

Officially recommended clients: Jedis, Redisson, and Lettuce.

Jedis

Lightweight, supports connection pool, pipelining, transactions, Lua, Sentinel, Cluster.

Does not provide built‑in read/write splitting; documentation is sparse.

Redisson

Netty‑based, asynchronous, high performance.

Supports connection pool, pipelining, Lua, Sentinel, Cluster, read/write splitting, and integrates with Spring Session.

Does not support native transactions; recommends Lua scripts instead.

Use Jedis for simple use‑cases; switch to Redisson when advanced features are required.