Common Redis Data Types, Memory Optimizations, and Persistence Mechanisms

Redis provides five core data structures: String, Hash, List, Set, and Sorted Set, each with specific commands (e.g., set, hget, lpush, sadd, zadd) and typical application scenarios.

Internally, every key/value is represented by a redisObject that stores a type and an encoding. For example, a String may be stored as raw bytes or as an integer when the value is numeric; a Hash uses either a compact zipmap or a full hash table depending on size; List is a doubly‑linked list; Set is a hash table with null values for fast deduplication; Sorted Set combines a hash table with a skip‑list to maintain order by score.

Redis offers several memory‑optimization parameters that control when compact encodings are used, such as hash-max-zipmap-entries, hash-max-zipmap-value, list-max-ziplist-entries, list-max-ziplist-value, and set-max-intset-entries. Adjusting these values balances memory savings against lookup performance.

The server supports four persistence mechanisms: snapshot (RDB) using forked copy‑on‑write, Append‑Only File (AOF) logging every write command, virtual memory (VM) which is deprecated, and an experimental diskstore based on B‑trees. Snapshot and AOF are production‑ready, while VM and diskstore remain experimental.

Because persistence writes use buffered I/O, large RDB or AOF files can cause significant page‑cache pressure, leading to memory over‑commit and possible crashes when Redis memory usage exceeds roughly 60 % of the host’s physical RAM.

Key recommendations: choose the appropriate data type for each use case, tune the compact‑encoding thresholds, disable VM, set maxmemory to protect against swapping, and select either snapshot or AOF based on tolerance for data loss, avoiding VM and diskstore in production.