Redis Architecture Options and Deployment Guide
This article reviews Redis's latest features and compares various deployment architectures—including single‑replica, dual‑replica, cluster, and read‑write‑separation modes—detailing their reliability, performance characteristics, suitable use cases, and provides a Java Jedis example for configuring a direct‑connect cluster.
The author, a senior architect, shares a comprehensive overview of Redis deployment options after researching multiple Redis deployment patterns for production environments.
Redis 6.0 New Features
New module system APIs
SSL/TLS encryption support
RESP3 protocol
Client‑side caching in multiple modes
Multithreaded I/O
Diskless replication for replicas
Redis‑benchmark supports cluster mode
Systemd rewrite support
Disque module support
Redis 5.0 New Features
Kernel optimizations, stable operation
Streams data type
Account management
Audit, slow, and operation logs
Snapshot‑based cache analysis
New Timers, Cluster, Dictionary module APIs
LFU/LRU info in RDB
Cluster manager moved to C implementation
Sorted set commands ZPOPMIN/ZPOPMAX/BZPOPMIN/BZPOPMAX
Active Defragmentation v2
Enhanced HyperLogLog
Improved memory statistics
HELP sub‑command for many commands
Better performance for frequent connect/disconnect
Jemalloc upgraded to 5.1
CLIENT ID and CLIENT UNBLOCK commands
LOLWUT command
Deprecation of the term "slave" (except for backward compatibility)
Network layer optimizations
Lua improvements
Dynamic HZ for balancing idle CPU usage
Core code refactoring and numerous improvements
Architecture Choices
Depending on business needs, choose among cluster, master‑replica, or read‑write‑separation architectures.
2.1 Master‑Replica (Dual‑Replica)
Provides high availability with automatic failover within 30 seconds; data persistence and backup are enabled by default.
2.2 Master‑Replica (Single‑Replica)
Suitable for pure cache scenarios without data reliability requirements; a node failure triggers a new Redis process and requires application warm‑up.
2.3 Cluster (Dual‑Replica)
Breaks Redis's single‑thread bottleneck using a sharded cluster where each shard runs a master‑replica pair. Supports both proxy and direct‑connect modes.
Proxy Mode
All client requests go through a single proxy address, simplifying development but adding a slight latency overhead.
Direct‑Connect Mode
Clients connect directly to shard nodes, reducing network overhead and response time; requires a Redis‑Cluster‑aware client such as Jedis.
2.4 Cluster (Single‑Replica)
Illustrated with diagrams; similar to dual‑replica but without replica redundancy.
2.5 Read‑Write‑Separation
Designed for read‑heavy workloads, offering high availability, high performance, and linear scalability by adding read‑only nodes.
Key Characteristics
High Availability : Automatic monitoring, failover, and node replacement.
High Performance : Chain replication allows linear performance growth with more read‑only nodes.
Use Cases
Ideal for scenarios with high read QPS, strict Redis protocol compatibility, or when migrating from standard Redis to a read‑write‑separated deployment.
Recommendations & Notices
If a read‑only node fails, traffic is rerouted to other nodes; if all read‑only nodes are down, traffic goes to the master, potentially increasing load.
Full synchronization may occur after a failover, during which the node returns a “‑LOADING” message.
Java Jedis Direct‑Connect Example
import redis.clients.jedis.*;
import java.util.HashSet;
import java.util.Set;
public class main {
private static final int DEFAULT_TIMEOUT = 2000;
private static final int DEFAULT_REDIRECTIONS = 5;
private static final JedisPoolConfig DEFAULT_CONFIG = new JedisPoolConfig();
public static void main(String args[]) {
JedisPoolConfig config = new JedisPoolConfig();
// Max idle connections, set according to business needs
config.setMaxIdle(200);
// Max total connections, set according to business needs
config.setMaxTotal(300);
config.setTestOnBorrow(false);
config.setTestOnReturn(false);
// Direct‑connect address obtained after enabling direct mode
String host = "r-bp1xxxxxxxxxxxx.redis.rds.aliyuncs.com";
int port = 6379;
// Instance password
String password = "xxxxx";
Set<HostAndPort> jedisClusterNode = new HashSet<>();
jedisClusterNode.add(new HostAndPort(host, port));
JedisCluster jc = new JedisCluster(jedisClusterNode, DEFAULT_TIMEOUT, DEFAULT_TIMEOUT,
DEFAULT_REDIRECTIONS, password, "clientName", config);
}
}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.
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
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.
