Redis Deep Dive: Core Concepts, Data Types, and Best Practices

Redis is an in‑memory key‑value database that offers high performance, multiple data structures, persistence, and various eviction policies, making it suitable for caching, messaging queues, leaderboards, and more.

1. What is Redis?

Redis is essentially a key‑value in‑memory database, similar to memcached, with the entire dataset loaded in memory and periodically flushed to disk asynchronously. Its pure memory operations enable it to handle over 100,000 reads/writes per second, making it one of the fastest key‑value stores.

2. Advantages of Redis over memcached

Supports richer data types beyond simple strings.

Much faster performance.

Provides data persistence.

3. Data types supported by Redis

String, List, Set, Sorted Set, Hashes.

4. Primary physical resource consumed by Redis

Memory.

5. Full name of Redis

Remote Dictionary Server.

6. Redis eviction policies

noeviction

: Returns an error when memory limit is reached and a write command is issued. allkeys-lru: Evicts the least recently used keys to make space. volatile-lru: Evicts LRU keys only among those with an expiration set. allkeys-random: Randomly evicts keys. volatile-random: Randomly evicts keys with an expiration. volatile-ttl: Evicts keys with the shortest remaining TTL.

7. Why Redis does not provide a Windows version

Because the Linux version is stable, widely used, and a Windows port would introduce compatibility issues.

8. Maximum size of a string value

512 MB.

9. Why Redis stores all data in memory

Storing data in memory provides the fastest read/write speed, while asynchronous disk writes ensure persistence. Without in‑memory storage, disk I/O would severely degrade performance.

10. Redis clustering solutions

Twemproxy – a proxy that uses consistent hashing to route requests to multiple Redis instances.

Codis – similar to Twemproxy but supports data migration when node counts change.

Redis Cluster 3.0 – built‑in clustering using hash slots and supports replica nodes.

Application‑level sharding – manually hash keys and route to specific instances.

11. When a Redis cluster becomes unavailable

If a three‑node cluster loses node B without replication, the cluster will consider the hash slot range 5501‑11000 missing and become unavailable.

12. Keeping hot data in Redis when MySQL holds 20 M rows

Redis will apply its eviction policy once the memory usage reaches the configured limit, ensuring only hot keys remain.

13. Typical Redis use cases

Session cache – provides persistence and fast access for user sessions.

Full‑page cache (FPC) – improves page load speed with persistent caching.

Message queues – List and Set structures enable efficient push/pop operations.

Leaderboards / counters – Sorted Sets and atomic increments support ranking systems.

Publish/Subscribe – enables real‑time messaging and chat systems.

14. Recommended Java clients

Redisson, Jedis, Lettuce, etc.; the official recommendation is Redisson.

15. Relationship between Redis and Redisson

Redisson is a high‑level distributed Java client that provides advanced data structures (e.g., Bloom filter, Map, Queue, Lock, etc.) built on top of Redis.

16. Comparison of Jedis and Redisson

Jedis offers comprehensive command coverage, while Redisson focuses on distributed Java data structures but lacks support for raw string operations, transactions, pipelines, and sharding.

17. Setting and authenticating a password

Set password: CONFIG SET requirepass 123456 Authenticate:

AUTH 123456

18. Concept of Redis hash slots

Redis Cluster uses 16,384 hash slots; each key’s CRC16 checksum modulo 16,384 determines its slot, and each node is responsible for a subset of slots.

19. Master‑slave replication model

Each master has N‑1 replicas to maintain availability when some nodes fail or lose communication.

20. Possibility of lost writes in a Redis cluster

Redis does not guarantee strong consistency; under certain conditions, write operations may be lost.

21. Replication mechanism between cluster nodes

Asynchronous replication.

22. Maximum number of nodes in a Redis cluster

16,384 nodes.

23. Database selection in Redis Cluster

Cluster does not support database selection; it always uses database 0.

24. Testing Redis connectivity

Use the PING command.

25. Purpose of pipelining

Pipelining allows sending multiple commands without waiting for individual replies, improving throughput.

26. Understanding Redis transactions

Transactions execute a sequence of commands atomically and in isolation; either all commands succeed or none are applied.

27. Transaction commands

MULTI

, EXEC, DISCARD, WATCH.

28. Setting expiration and persistence

Use EXPIRE to set a TTL and PERSIST to make a key permanent.

29. Memory optimization tips

Prefer hashes to store many small fields together, reducing overhead compared to many separate keys.

30. How the Redis eviction process works

A client issues a command that adds new data.

Redis checks memory usage; if it exceeds maxmemory, it evicts keys based on the configured policy.

New commands continue to be processed, repeating the check.

31. Eviction algorithm used

LRU (Least Recently Used).

32. Bulk data insertion

Since Redis 2.6, redis-cli supports a pipe mode for massive data loads.

33. Reason for sharding Redis

Sharding allows Redis to use the combined memory of multiple machines, scaling both storage capacity and network bandwidth.

34. Sharding implementation approaches

Client‑side sharding – the client decides which node stores each key.

Proxy sharding – a proxy routes requests to appropriate nodes (e.g., Twemproxy).

Query routing – the client contacts any node, which then redirects to the correct node (as in Redis Cluster).

35. Drawbacks of sharding

Multi‑key operations (e.g., set intersections) may not be supported.

Transactions across multiple keys are limited.

Key‑level granularity prevents sharding a single massive sorted set.

Backup and monitoring become more complex.

Dynamic scaling can be difficult for some sharding methods.

36. Scaling persistence vs. cache usage

Cache scenario – use consistent hashing for dynamic scaling.

Persistent storage – require a fixed key‑to‑node mapping; only Redis Cluster supports runtime rebalancing.

37. When to adopt a distributed Redis architecture

Because a single Redis instance uses minimal memory, it is advisable to start with multiple instances (e.g., 32‑64) and sharding from the beginning, simplifying future scaling.

38. What is Twemproxy?

Twemproxy is a fast, single‑threaded proxy maintained by Twitter that supports the Memcached and Redis protocols, provides automatic sharding, and can exclude failed nodes.

39. Clients that support consistent hashing

Redis‑rb, Predis, etc.

40. Differences between Redis and other key‑value stores

Rich data structures with atomic operations.

In‑memory operation with optional persistence, offering superior speed for complex data.

41. Redis memory consumption example

One million simple key‑value pairs (key 0‑999999, value "hello world") consume about 100 MB on a 32‑bit Mac; storing all values under a single key reduces usage to ~16 MB.

42. Reducing Redis memory usage

On 32‑bit instances, pack many small fields into hashes, lists, sets, or sorted sets to minimize overhead.

43. Command to view Redis status

INFO

44. Behavior when Redis memory is exhausted

Write commands return errors, while reads continue; with an eviction policy enabled, old data is removed to free space.

45. Improving multi‑core utilization

Run multiple Redis instances on the same server or shard data across several instances to leverage multiple CPUs.

46. Maximum number of keys and collection elements

Redis can theoretically handle up to 2³² keys; in practice, instances have stored over 250 million keys. Lists, Sets, and Sorted Sets can each hold up to 2³² elements.

47. Common performance issues and solutions

Avoid persistence on the master (RDB snapshots, AOF).

Enable AOF on slaves for important data, syncing every second.

Place master and slaves in the same LAN for low latency.

Do not add slaves to an already heavily loaded master.

Prefer a linear master‑slave chain (Master ← Slave1 ← Slave2 …) for stability.

48. Persistence options

RDB snapshots at intervals.

AOF logs every write operation, with background rewriting to limit size.

No persistence (data exists only while the server runs).

Both RDB and AOF simultaneously; on restart, AOF is preferred.

49. Choosing a persistence strategy

For PostgreSQL‑level safety, enable both RDB and AOF. If occasional data loss of a few minutes is acceptable, RDB alone may suffice.

50. Applying configuration changes without restart

Many settings can be changed at runtime with CONFIG SET. Since Redis 2.2, you can switch between AOF and RDB without restarting. Some parameters still require a restart.