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

Overview

Redis is an open‑source, in‑memory data store that can serve as a database, cache, or message broker. It supports strings, hashes, lists, sets, sorted sets, bitmaps, and HyperLogLog, operates on a single‑threaded, non‑blocking I/O model, and offers O(1) command performance for most operations.

Data Structures and Common Commands

Redis uses a key‑value model; good key design (e.g., object-type:id:attr) improves readability and memory usage. Key commands include SET , GET , INCR , and MSET . List commands such as LPUSH , RPUSH , LPOP , RPOP , and LRANGE enable queue‑like usage. Hash commands ( HSET , HGET , HSCAN ) map naturally to object fields. Set commands ( SADD , SREM , SINTER , SUNION ) support unordered collections, while sorted‑set commands ( ZADD , ZRANGE , ZSCORE ) are ideal for ranking. Bitmap and HyperLogLog provide space‑efficient boolean storage and cardinality estimation.

Persistence

Redis offers two persistence mechanisms: RDB snapshots and AOF logs. RDB creates point‑in‑time snapshots with minimal performance impact; AOF records every write operation for higher durability. Example configurations: save 60 100 means a snapshot is taken every 60 seconds if at least 100 keys changed. appendonly yes enables AOF. AOF rewrite can be tuned with:

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64 mb

Memory Management and Eviction

Set an upper memory limit, e.g., maxmemory 100mb. When the limit is reached Redis evicts keys according to a policy. Supported policies are volatile-lru, allkeys-lru, volatile-random, allkeys-random, and volatile-ttl. The commonly recommended default is volatile-lru, which evicts the least‑recently‑used keys that have an expiration.

Pipelining, Transactions and Scripting

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

SET a "abc"

INCR b

HSET c name "hi"

Transactions guarantee atomic execution using MULTI / EXEC. WATCH adds optimistic locking for CAS‑style updates. Lua scripting via EVAL or EVALSHA can replace many transaction use‑cases, providing server‑side execution of complex logic.

Performance Tuning

Avoid long‑running commands such as KEYS , large HGETALL , or full ZRANGE . Use cursor‑based SCAN , HSCAN , SSCAN , ZSCAN instead. Disable Transparent Huge Pages, monitor slow queries with SLOWLOG GET, and consider read‑write separation to offload read traffic.

Replication, Sentinel and Cluster

Master‑slave replication enables read‑write separation; slaves can serve read‑only traffic. Redis Sentinel monitors instances and performs automatic failover when the master disappears. Redis Cluster shards data across 16384 hash slots, automatically routing requests to the correct node. Hash tags (e.g., {user}id:1000) keep related keys in the same slot, which is required for multi‑key operations like pipelines, transactions, or Lua scripts.

Java Client Choices

Two popular Java clients are highlighted:

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

Redisson : Netty‑based, asynchronous, provides read‑write splitting, advanced features such as distributed locks and Spring Session integration, supports pipelining and Lua scripting, but does not offer native transaction support.

Choose the client that matches the required feature set and complexity of the application.