From Simple Cache to Distributed System: Understanding Redis’s Evolution
This article walks through Redis’s role as an in‑memory data store, explains how simple HTTP caching evolves into server‑side memory caching, and details the progression to high‑availability and distributed architectures with persistence, Sentinel, replication, clustering, and advanced features like transactions, Lua scripting, pipelining, and distributed locks.
What is Redis?
Redis is an open‑source, BSD‑licensed project that stores structured data in memory. It can be used as a database, cache, and message broker, supporting strings, lists, hashes, sets, sorted sets, bitmaps, hyperloglogs, and geospatial indexes, along with features such as replication, Lua scripting, LRU eviction, transactions, Sentinel for high availability, and Cluster for automatic sharding.
From Simple Cache to In‑Memory Cache
Initially, an API providing hot news ( http://api.xxx.com/hot-news) suffered ~2 seconds latency per request. The first improvement added an HTTP Cache‑Control: max‑age=600 header, allowing clients to cache responses for ten minutes. While this reduced perceived latency, it introduced stale data and did not eliminate the server‑side delay.
To address the root cause—SQL queries taking ~2 seconds—the result was cached directly in the API server’s memory for one minute. Subsequent requests within that minute read the cache, eliminating the database round‑trip and dramatically improving response time, assuming a request rate of 100 QPS (≈6000 requests per minute).
When many services adopted this pattern, the API servers’ memory became saturated, prompting the move to a dedicated Redis server with ample memory.
Introducing Redis Server
Deploying Redis on a separate machine offloads caching from API servers, solving memory pressure while providing a centralized, high‑performance cache.
High Availability: Persistence, Sentinel, Replication
Redis persistence writes in‑memory data to disk, allowing recovery after a server crash and mitigating cache‑snowball effects. Sentinel monitors multiple Redis instances, sends alerts, and performs automatic failover, while replication creates one‑or‑many read‑only replicas to ensure data redundancy and enable read‑write separation.
Scaling with Redis Cluster
Single‑node memory limits necessitate horizontal scaling. Redis Cluster distributes data across multiple nodes using 16,384 hash slots. Clients compute CRC16(key) % 16384 to determine the slot; each node owns a subset of slots. Adding or removing nodes triggers slot migration, and each node maintains the full slot‑to‑node map to redirect client requests without a separate proxy.
Data Types
String – binary‑safe up to 512 MB.
List – ordered collection of strings.
Set – unordered collection of unique strings.
Sorted Set – ordered by score.
Hash – map of field‑value pairs.
Bitmap – bit‑level operations.
HyperLogLog – probabilistic cardinality estimator.
These structures enable efficient handling of diverse use cases, reducing network overhead compared to naïve string‑only approaches.
Advanced Features: Transactions, Lua, Pipelining, Distributed Locks
Redis transactions execute multiple commands atomically. For more complex server‑side logic, Lua scripts run atomically and can replace transaction commands (e.g., extending a key’s TTL while fetching its value).
Pipelining batches multiple commands over a single TCP connection, lowering round‑trip latency, though it does not guarantee atomicity.
Distributed locks are implemented via the Redlock algorithm, using a string key with a random value and a Lua script to release the lock safely:
<code>SET resource_name my_random_value NX PX 30000
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
endSummary
The article abstracts Redis’s capabilities—from basic in‑memory storage to high‑availability, sharding, and advanced command features—highlighting why each function exists and how it solves specific problems, enabling developers to choose appropriate solutions without being constrained by low‑level implementation details.
Redis 文档:https://github.com/antirez/redis-doc
Redis 简介:https://redis.io/topics/introduction
Redis 持久化:https://redis.io/topics/persistence
Redis 发布/订阅:https://redis.io/topics/pubsub
Redis 哨兵:https://redis.io/topics/sentinel
Redis 复制:https://redis.io/topics/replication
Redis 集群:https://redis.io/topics/cluster-tutorial
Redis 事务:https://redis.io/topics/transactions
Redis 数据类型:https://redis.io/topics/data-types-intro
Redis 分布式锁:https://redis.io/topics/distlock
Redis 管道:https://redis.io/topics/pipelining
Redis Lua 脚本:https://redis.io/commands/evalSigned-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITPUB
Official ITPUB account sharing technical insights, community news, and exciting events.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
