Databases 45 min read

Redis Deep Dive: Core Concepts, Performance, Persistence, and Scaling Strategies

This comprehensive guide explains what Redis is, its advantages and drawbacks, why it excels as a high‑performance cache, the supported data structures, persistence mechanisms, memory eviction policies, threading model, transaction handling, clustering and sharding options, distributed locking, common cache pitfalls, and useful tooling for Java developers.

Open Source Linux
Open Source Linux
Open Source Linux
Redis Deep Dive: Core Concepts, Performance, Persistence, and Scaling Strategies

What Is Redis?

Redis (Remote Dictionary Server) is an open‑source, high‑performance, in‑memory key‑value store written in C and licensed under BSD.

It stores keys as strings and supports five value types: strings, lists, sets, sorted sets, and hashes.

Advantages

Exceptional read/write speed (up to 110,000 reads/s and 81,000 writes/s).

Supports persistence via RDB snapshots and AOF logs.

All operations are atomic; supports transactions.

Rich data structures enable various use cases.

Master‑slave replication allows read/write separation.

Disadvantages

Memory‑limited; unsuitable for massive datasets.

No automatic failover; master failure can cause downtime.

Data may be lost between snapshots.

Online scaling is complex and may waste resources.

Why Use Redis / Why Use a Cache?

Redis provides high performance and high concurrency by keeping data in memory, making reads and writes extremely fast. Caching reduces latency for frequently accessed data and offloads read traffic from databases.

Redis cache diagram
Redis cache diagram

Data Types

Redis offers five primary data structures:

String : Simple key‑value pairs.

Hash : Field‑value maps, ideal for objects.

List : Ordered collections, useful for queues.

Set : Unordered unique elements, supports set operations.

Sorted Set (Zset) : Ordered by score, perfect for leaderboards.

Redis data types
Redis data types

Persistence

What Is Persistence?

Persistence writes in‑memory data to disk to prevent loss on crashes.

RDB (Snapshot)

Creates a dump.rdb file at configured intervals.

Fast startup, low CPU impact.

Potential data loss between snapshots.

AOF (Append‑Only File)

Logs every write command.

Higher durability (especially with appendfsync always).

Larger files and slower recovery.

Choosing Persistence

Use both RDB and AOF for maximum safety.

RDB only if a few minutes of data loss is acceptable.

Only AOF for high durability, but be aware of slower restarts.

Memory Management

Eviction Policies

noeviction : New writes are rejected when memory is full.

allkeys‑lru : Evicts least recently used keys (most common).

allkeys‑random : Random eviction.

volatile‑lru , volatile‑random , volatile‑ttl : Apply only to keys with an expiration.

Memory Usage

Redis primarily consumes RAM; CPU usage is minimal due to its single‑threaded design.

Thread Model

Redis uses a single‑threaded Reactor pattern with non‑blocking I/O, handling multiple sockets in one thread for simplicity and high performance.

Transactions

Transactions are executed atomically using MULTI, EXEC, DISCARD, and WATCH. Commands are queued after MULTI and executed in order on EXEC. Redis does not support rollback; if a command fails, the rest still run.

Clustering and Sharding

Sentinel

Provides monitoring, notification, automatic failover, and configuration updates for high availability.

Redis Cluster

Uses 16,384 hash slots; keys are assigned to slots via CRC16. Nodes own subsets of slots and redirect clients to the correct node.

Client‑Side Sharding

Clients hash keys to determine the target node, enabling horizontal scaling.

Proxy Sharding (Twemproxy, Codis)

Clients send requests to a proxy that forwards them to the appropriate Redis instance.

Distributed Locking

Implemented with SETNX (set if not exists) and an expiration to avoid deadlocks. RedLock is a more robust algorithm using multiple Redis nodes.

Cache Pitfalls

Cache Avalanche

Mass expiration can overload the database; mitigate by randomizing TTLs and using locks.

Cache Penetration

Requests for non‑existent keys bypass cache; mitigate with Bloom filters or caching null results.

Cache Breakdown (Hot Key)

When a hot key expires, many concurrent requests hit the DB; mitigate with mutex locks or keeping hot keys permanent.

Cache Warm‑up

Pre‑load critical data into cache at startup or via scheduled jobs.

Cache Degradation

When cache is unavailable, gracefully fall back to default values or reduced functionality.

Common Tools

Redisson : Officially recommended Java client with distributed objects.

Jedis : Basic Java client supporting most Redis commands.

Lettuce : Reactive Java client.

Other Topics

Redis vs. Memcached: Redis offers richer data types, persistence, and higher performance.

Ensuring DB‑Cache Consistency: Update DB first, then delete or update cache; or serialize writes.

Performance Tips: Avoid heavy persistence on masters, use slaves for backups, keep replication within LAN, and monitor memory limits.

Why No Official Windows Build: Focus on stable Linux support.

String Size Limit: 512 MB per key.

Bulk Insertion: Use Redis CLI pipe mode.

Key Scanning: Prefer SCAN over KEYS in production.

Asynchronous Queues: Use LPUSH / LPOP or BLPOP for reliable queues.

Delayed Queues: Use ZADD with timestamps as scores.

Memory Reclamation: Triggered when maxmemory is exceeded, using LRU algorithm.

Author: ThinkWon Original article: https://thinkwon.blog.csdn.net/article/details/103522351
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

rediscachingPersistenceClusterdistributed-lockIn-Memory Database
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.