Master Redis: Data Structures, Commands, and Performance Tuning Explained

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, and HyperLogLog, and provides features such as LRU eviction, transactions, persistence, replication, Sentinel‑based high availability, and automatic sharding via Redis Cluster.

Data Structures and Common Commands

Key

Keys are binary strings; keep them short, readable, and follow a naming convention like object-type:id:attr. Maximum key length is 512 MB.

String

Strings are the basic type; numeric operations are performed with commands such as INCR, INCRBY, and DECR (all O(1)). Common commands:

SET – set a value (optional expiration, NX/XX flags)

GET – retrieve a value

GETSET – set and return the old value

MSET / MSETNX – multi‑key set

MGET – multi‑key get

List

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

LPUSH / RPUSH – push elements

LPOP / RPOP – pop elements

LLEN – length

LRANGE – range query (avoid large ranges)

Avoid using List as a general array; prefer it for FIFO queues. Use blocking commands BLPOP / BRPOP for queue semantics.

Hash

Hashes store field‑value pairs, ideal for representing objects. Common commands:

HSET / HGET

HMSET / HMGET – batch operations

HDEL – delete fields

HINCRBY – numeric increment

For large hashes, avoid HGETALL, HKEYS, HVALS; use HSCAN instead.

Set

Sets are unordered collections of unique strings. Common commands:

SADD / SREM

SISMEMBER – membership test

SCARD – cardinality

SUNION / SINTER / SDIFF – set operations (use with caution on large sets)

Prefer client‑side set operations for very large collections.

Sorted Set

Sorted sets store unique members with a score, enabling ranking. Common commands:

ZADD / ZREM

ZCARD – cardinality

ZCOUNT – count by score range

ZINCRBY – increment score

ZRANK / ZREVRANK – rank lookup

Avoid full scans like ZRANGE 0 -1; use ZSCAN or limit the result set.

Bitmap & HyperLogLog

Bitmaps treat strings as bit arrays for compact true/false storage. HyperLogLog provides approximate distinct‑count estimation with very low memory overhead.

Performance Tuning

Redis is fast but can suffer latency from long‑running commands, OS settings, persistence, swap, or massive key expirations.

Avoid O(N) commands on large collections (e.g., KEYS, large HGETALL, SUNION).

Use pipelining to batch commands.

Disable Transparent Huge Pages:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Prefer physical machines over VMs for latency‑critical workloads.

Configure persistence wisely (AOF fsync policies, RDB snapshot frequency).

Monitor and limit swap usage; avoid memory pressure.

Stagger key expirations to prevent eviction spikes.

Consider read‑write splitting: replicas serve read‑only traffic.

Long‑Running Commands

Identify and limit commands whose time complexity grows with data size. Use SLOWLOG to capture slow operations:

slowlog-log-slower-than xxxms  # threshold

slowlog-max-len xxx          # max entries

Retrieve with SLOWLOG GET [number] and reset with SLOWLOG RESET.

High Availability

Replication & Sentinel

Redis master‑slave replication copies writes from the master to one or more slaves. Sentinel monitors instances, performs automatic failover, and updates client configurations. Minimal Sentinel deployment requires 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

Scaling with Redis Cluster

Cluster shards data across up to 16384 hash slots. Keys are assigned to slots via CRC16 modulo 16384. Clients can connect to any node; the cluster redirects requests to the correct slot.

Hash tags (e.g., {user}id:1) force multiple keys into the same slot, enabling multi‑key operations like pipelines, transactions, or Lua scripts.

Cluster vs. Replication

Cluster solves data‑size and write‑throughput limits of a single node, while also providing built‑in replication. However, it adds operational complexity, higher client resource consumption, and stricter constraints on transactions and scripts.

When to Choose Cluster

Adopt Cluster only if memory or write load exceeds a single node’s capacity, and you can handle the added management overhead. Otherwise, master‑slave replication with Sentinel is simpler and sufficient.