Understanding Redis Data Structures, Clustering, and Core Operations

Redis stores every value as a binary byte array (byte[]), so there are no intrinsic data types; types appear only after decoding the bytes into strings, integers, or objects. Consequently, any data that can be represented as a byte array can be stored in Redis.

The five logical data structures are:

String : a simple key‑value pair where both key and value are byte arrays.

List : an ordered collection of values that may contain duplicates.

Set : an unordered collection of unique values.

Hash : a map of field‑value pairs accessed by field name rather than position.

Sorted Set : like a Set but each member has an associated floating‑point score that determines ordering.

When Redis is deployed as a cluster, two main challenges arise: deciding which node stores a given key (data allocation) and moving data when nodes are added or removed (data migration). Redis solves this by introducing a fixed set of 16,384 slots and mapping each key to a slot using a hash function.

The slot for a key is computed as follows: slot = CRC16(key) % 16384 Each slot is assigned to a master node; the client caches the slot‑to‑node mapping, calculates the slot for a key, and sends the request directly to the responsible node. If the cluster topology changes, the node may respond with a -MOVED redirection, prompting the client to retry the request on the correct node.

Redis clusters also support key hash tags (e.g., {user1000}.followers) so that multiple related keys share the same hash slot while remaining distinct.

Redis uses a single‑threaded event‑driven model (epoll) for each node because all operations are in‑memory, network latency dominates, and multithreading would add locking overhead and complexity.

Transactions in Redis are implemented with MULTI, EXEC, WATCH, and DISCARD. They guarantee atomic execution of queued commands but do not provide rollback on errors, and errors encountered during execution are not abortive.

Pipeline mode allows a client to send multiple commands without waiting for individual replies, then read all responses in sequence, greatly reducing round‑trip latency. However, Redis clusters do not support pipelining across multiple keys that reside on different nodes.

The Redis wire protocol is a simple text‑based format. Requests start with * followed by the number of arguments, then each argument is prefixed with $ and its byte length. Responses are indicated by a leading character: + for simple strings, - for errors, : for integers, $ for bulk strings, and * for arrays.

Overall, Redis focuses on fast, in‑memory key/value operations, keeping the core simple and avoiding features that would compromise performance or increase complexity.