Core Concept
Redis is a single threaded, in-memory key-value store. Known for its incredible speed and the fact that a single Redis server can handle around 100k QPS. It's speed comes from its operations which is run purely on memory, whereas most other databases rely on disk.
It avoids the complexity of locking mechanisms and race conditions. Since Redis is CPU-bound (operations are simple memory reads/writes), the bottleneck is usually the Network I/O, not the CPU execution time.
Data Structures
| Data Structure | Fundamental Concept | Potential Use Case |
|---|---|---|
| String | Key-Value | Caching (HTML fragments, JSON blobs), Distributed Locks (SETNX). |
| List | Linked List (Doubly) | Message Queues (Twitter timelines, job queues). O(1) push/pop. |
| Set | Unordered Unique collection | Social Graphs (User A follows User B), Tags, filtering duplicates. |
| Sorted Set (ZSet) | Unique collection + Score | Leaderboards (Gaming), Priority Queues, Rate Limiting (Sliding Window Log). |
| Hash | Map within a key | Object Storage (User Sessions, Profiles). Saves memory vs. serializing JSON strings. |
| HyperLogLog | Probabilistic Data Structure | Analytics (Unique visitors count). Uses constant small memory (12kb) for millions of items with <1% error. |
| Bloom Filter | Probabilistic (Module/Bitmaps) | Existence Checks (Did this user already read this post?). Prevents cache penetration. |
| Geospatial | Geo-indexing | Proximity Search (Uber/Lyft "drivers near me"). |
Replication
high level notes
- replication is async
- non-blocking on master
- replicas are read-only
Why would we need replication?
- high availability
- spread of read load
- can be used in place of persistence
Data Persistence
Redis does have the ability to save data onto disk and uses two mechanisms.
- Redis Database (RDB): A point in time snapshot of the current data is saved to disk as defined intervals.
- pro: Compact file format, faster startups
- con: Data loss window
- Append Only File (AOF): Every write option is written to a file which can be read back in order to restore.
- pro: High durability, can sync every second
- con: Large file size, slower replay on restart
Clusters
Custer information uses gossip protocols. Each node knows the state of every other node including:
- role
- availability
- hash slots they serve Each node will periodically will send a heartbeat message to another random sub-set of nodes.
Cluster data sharding uses hash slot. There are 16384 hash slots in Redis Cluster and computing a hash: CRC16(key) % 16384.
For example, a Redis Cluster with 3 nodes:
- Node A contains hash slots from 0 to 5500.
- Node B contains hash slots from 5501 to 11000.
- Node C contains hash slots from 11001 to 16383.
Redis Streams Vs. Kafka
Redis Streams gives you Kafka-like semantics (consumer groups, offsets, append-only log) but within Redis itself. The trade-off: Redis Streams is simpler to set up and great for moderate throughput, but Kafka is purpose-built for high-throughput, multi-consumer event streaming with durable partitioned storage across a cluster. If you're already running Redis and don't need Kafka-scale, Streams can save you an entire infrastructure layer.
RESP Protocol
RESP is a binary protocol that uses control sequences encoded in ASCII.
Payload Structure
The first byte of every RESP message acts as a type indicator, determining how the rest of the payload should be parsed:
| Type Indicator | Data Type | Structure | Example |
|---|---|---|---|
+ | Simple String | +<string>\r\n | +OK\r\n |
- | Error | -<error message>\r\n | -ERR unknown command\r\n |
: | Integer | :<number>\r\n | :1000\r\n |
$ | Bulk String | $<length>\r\n<data>\r\n | $6\r\nfoobar\r\n |
* | Array | *<count>\r\n<elements> | *2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n |
Key Points:
- Simple Strings and Errors are human-readable, single-line responses
- Bulk Strings are binary-safe and prefixed with their length
- Arrays can contain nested RESP messages of any type
\r\n(CLRF) is the terminator for this protocol.