Mastering Redis: Advanced Types, Replication, Persistence, and Real-World Design
This article explores Redis’s advanced features—including data types, master‑slave, sentinel, and cluster architectures, transaction handling, RDB/AOF persistence, pub/sub messaging, and a practical e‑commerce search case study—providing design insights and best‑practice configurations for high‑availability and performance.
This article introduces several advanced features of Redis and analyzes its design through a concrete real‑world case.
Review of Redis Basic Types
String
Redis strings are the simplest data type; the value can be a plain string or a complex string such as JSON. Objects are often serialized (e.g., with fastjson) and stored as strings. Using MGET for batch retrieval improves efficiency.
Hash
Hashes are suitable for storing objects and consume less memory than strings. They allow updating a single field without rewriting the whole object, similar to updating a column in a relational database. Example: store a user object with KEY: User, FIELD: USERID, VALUE: serialized string.
List
Lists can act as stacks or queues. Their FIFO or LIFO characteristics are useful for leaderboards, real‑time lists, or simple message queues.
Set
Sets are unordered collections of unique strings. They support set operations such as intersection, union, and difference, which are handy for scenarios like finding common followers or fans.
ZSet
ZSet (sorted set) is used for ranking scenarios where ordering is required.
Three Redis Deployment Modes: Master‑Slave, Sentinel, Cluster
Redis has evolved from the master‑slave mode in version 1.x, to sentinel in 2.x, and to cluster in 3.x, each improving reliability and high availability.
Master‑Slave Mode
In the early reliability solution, the master handles reads and writes, while slaves are read‑only.
Configuration is simple: set the master’s IP, port, and password on each slave.
Master info
Slave info
A master can have multiple slaves, and replication does not block the master; it can continue serving client requests while syncing.
Sentinel Mode
Sentinel addresses the single‑point‑failure of the master‑slave model by monitoring the master’s heartbeat and automatically electing a new master from the slaves when the original master fails.
Sentinel can be deployed on any node; multiple sentinel instances are recommended to avoid a single point of failure.
sentinel monitor mymaster 192.168.99.121 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 2Key configuration items include the master’s IP and port, the vote count required for a slave to become master, heartbeat frequency, and the number of slaves under the master.
Cluster Mode
Redis Cluster is widely used today; it supersedes earlier sharding techniques and further enhances data reliability, distribution, and service availability. Detailed coverage will be provided in a subsequent article.
Simple Transactions in Redis
Redis supports simple transactions using MULTI to start and EXEC to commit. However, Redis does not provide atomic rollback; if an error occurs, previously executed commands are not undone, unlike MySQL.
Redis Persistence Mechanisms
Redis can persist data to disk using two methods.
RDB (Snapshot)
RDB creates point‑in‑time snapshots saved as dump.rdb. The snapshot is triggered when a configurable number of keys change within a given time interval (e.g., N seconds and M key modifications).
AOF (Append‑Only File)
AOF logs every write command. Upon restart, Redis replays the logged commands to reconstruct the dataset, providing higher durability than RDB, especially when using the always sync strategy.
Publish/Subscribe Messaging
Pub/Sub is straightforward: a client subscribed to a channel receives every message published on that channel. This pattern is widely used in message‑oriented middleware such as ActiveMQ or RocketMQ.
Redis Case Design Analysis
Consider an e‑commerce platform with millions of products (e.g., JD.com). Direct MySQL queries are insufficient for fast search; a Redis layer can accelerate lookups.
Loading MySQL data into Redis and traversing Hashes for queries works for small loads but does not scale for high‑traffic platforms with diverse search criteria.
Design approach: pre‑create Sets representing various product attribute groups (e.g., category, brand). User search criteria translate into set operations (intersection, union, difference). The resulting Set yields a narrowed list of ProductIDs, dramatically reducing the search space compared to scanning all products.
Although Redis is easy to use, effective designs require combining its data structures thoughtfully according to business scenarios.
Signed-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.
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
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.
