Comprehensive Redis Guide: Data Structures, Commands, Persistence, Performance Tuning, and Deployment Strategies

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, offers single‑threaded atomic operations, and provides replication, high‑availability, and clustering capabilities.

Data Structures and Common Commands

Key

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

String

Basic type for all values. Frequently used commands include SET , GET , GETSET , MSET , MSETNX , MGET , and integer‑or‑float operations such as INCR , INCRBY , DECR , DECRBY .

Example – Inventory Control

Set total stock:

SET inv:remain "100"

Decrement on each purchase:

DECR inv:remain

If the returned value is ≥ 0 the purchase succeeds; otherwise the stock is exhausted.

Example – Auto‑Increment Sequence

Initialize sequence:

SET sequence "10000"

Get next value:

INCR sequence

Reserve a block of 100 values:

INCRBY sequence 100

List

Linked‑list structure. Useful commands: LPUSH , RPUSH , LPOP , RPOP , LLEN , LRANGE . Avoid O(N) operations on large lists; use lists as queues rather than random‑access arrays.

Hash

Field‑value map, ideal for representing objects. Common commands: HSET , HGET , HMSET , HMGET , HSETNX , HEXISTS , HDEL , HINCRBY . For large hashes, prefer HSCAN over HGETALL , HKEYS , HVALS .

Set

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

Sorted Set

Ordered set with a score per member. Core commands: ZADD , ZREM , ZCOUNT , ZCARD , ZSCORE , ZRANK , ZREVRANK , ZINCRBY . Use ZSCAN instead of ZRANGE 0 -1 on big sorted sets.

Bitmap & HyperLogLog

Bitmap is a string used as a bit array; HyperLogLog provides approximate distinct‑counting with very low memory usage. See Redis docs for detailed usage.

Other Useful Commands

EXISTS , DEL , EXPIRE/PEXPIRE , TTL/PTTL , RENAME/RENAMENX , TYPE

CONFIG GET , CONFIG SET , CONFIG REWRITE

Persistence

RDB

Snapshotting to a binary file. Configured with save directives (e.g., save 60 10000 ) or triggered manually via BGSAVE . Advantages: minimal performance impact, fast recovery. Disadvantages: possible data loss between snapshots, fork overhead on large datasets.

AOF

Append‑only log of every write operation. Enabled with appendonly yes . Three fsync policies: always (safest, slowest), everysec (balanced), no (fastest). AOF can be rewritten to compact the log using BGREWRITEAOF or auto‑rewrite settings.

Memory Management & Eviction

Default maxmemory is 3 GB on 32‑bit OS, unlimited on 64‑bit. Set a limit with maxmemory 100mb . When the limit is reached, Redis applies an eviction policy such as volatile-lru , allkeys-lru , volatile-random , allkeys-random , or volatile-ttl . volatile-lru is generally recommended.

Pipelining

Pipelining batches multiple commands in a single network round‑trip, reducing latency. Example:

printf "PING\r\nPING\r\nPING\r\n" | nc localhost 6379

Most client libraries support pipelining automatically.

Transactions & Scripting

Use MULTI / EXEC to execute a group of commands atomically. Redis does not support rollback; syntax errors abort the transaction, but runtime errors may still execute partially. Optimistic locking is provided by WATCH + EXEC .

Lua scripting via EVAL or EVALSHA can replace many transaction use‑cases and runs on the server side for higher efficiency.

Performance Optimization

Avoid long‑running O(N) commands on large collections; prefer SCAN family.

Use pipelining for bulk operations.

Disable Transparent Huge Pages on the OS.

Prefer physical machines over VMs for latency‑critical workloads.

Tune persistence (RDB vs AOF) based on safety vs speed requirements.

Monitor slow logs with SLOWLOG GET and configure slowlog‑log‑slower‑than .

Replication & Sentinel

Master‑slave replication provides read‑write separation and high availability. Slaves sync via RDB snapshot followed by incremental replication. Sentinel monitors masters, performs automatic failover, and updates clients with the new master address. Minimum three Sentinel instances are recommended.

Cluster Sharding

Redis Cluster distributes data across 16384 hash slots. Keys are assigned to slots using 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, which is required for cross‑key operations like pipelines, transactions, or Lua scripts.

Cluster offers automatic sharding and built‑in replication, but adds operational complexity, higher client resource consumption, and restrictions on multi‑key commands.

Java Client Selection

Popular clients: Jedis (lightweight, supports pooling, pipelining, transactions, Lua, Sentinel, Cluster; no built‑in read‑write splitting) and Redisson (Netty‑based, async API, supports pipelining, Lua, Sentinel, Cluster, read‑write splitting, but lacks transactions). Choose based on required features and complexity.