Advanced Guide to Redis: Data Structures, Usage, Internals, Performance Issues, and Security

Redis is a widely used in‑memory data store. While many developers only use it at a surface level, this article provides an in‑depth guide covering basic data structures, advanced features, internal mechanisms, performance bottlenecks and security best practices.

1. Basic data structures

String – dynamic strings that grow automatically. When the length is under 1 MiB the string size doubles; beyond 1 MiB it grows by 1 MiB increments up to 512 MiB.

List – implemented as a linked list; small lists use a ziplist (compressed list) and large lists switch to a quicklist. Commonly used as an asynchronous queue with RPUSH/LPOP etc.

Set – an unordered collection similar to Java’s HashSet; useful for deduplication such as lottery draws.

Hash – a map structure; rehashing works like Go’s map implementation, maintaining two hash tables during expansion.

Zset – a sorted set backed by a skip‑list; each element has a score that determines order.

2. Advanced usage

Bloom filter (available from Redis 4.0 as a module) provides probabilistic deduplication.

bf.add #添加元素

bf.exists #判断元素是否存在

bf.madd #批量添加

bf.mexists #批量判断是否存在

Distributed lock using SETNX and DEL (with optional expiration to avoid dead‑locks).

setnx lock:mutex true #加锁

del lock:mutex #删除锁

Cluster key routing uses CRC16(key) & 16383 to map a key to a slot. Example command:

set key value

3. Deep internal principles

IO model – Redis runs a single‑threaded event loop for command processing while using a separate thread/process for persistence and replication.

Communication protocol – Redis Cluster uses a Gossip protocol to disseminate state information among nodes.

Persistence – RDB (snapshot), AOF (append‑only file) and hybrid persistence (RDB + incremental AOF) are supported.

Master‑slave replication – data is first transferred via RDB, then incremental changes are streamed via AOF.

Sentinel – monitors a set of Sentinel nodes (typically 3‑5) to detect master failures and perform automatic failover.

Cluster – 16384 hash slots are evenly distributed among master nodes; slots are reassigned when nodes join or leave.

4. Why Redis may become slow

Heavy commands (SORT, SUNION, ZUNIONSTORE) or large keys cause CPU spikes.

Large data transfers and network bandwidth saturation.

Memory fragmentation and automatic defragmentation.

Frequent AOF fsync or high write‑throughput.

Blocking commands such as FLUSHDB/FLUSHALL.

Large key migrations in a clustered environment.

Single‑threaded IO becomes a bottleneck under high concurrency.

5. Security recommendations

Bind Redis to a specific IP, enable ACLs, require AUTH, and place Redis behind a trusted proxy (since native SSL is not supported). Limit client access and use firewalls to restrict the default 6379 port.