Choosing the Right Redis Deployment: Versions, Features, and Architecture Explained

When writing an open‑source project, I realized the need to support multiple Redis deployment modes, so I investigated production‑environment architecture options.

Engine Versions

Redis 6.0 New Features

Module system adds multiple APIs.

Supports SSL/TLS encryption.

Supports new Redis protocol RESP3.

Server supports client‑side caching in multiple modes.

Supports multithreaded I/O.

Diskless replication in replicas.

Redis‑benchmark adds Redis cluster mode.

Supports rewriting Systemd.

Supports Disque module.

Redis 5.0 New Features

Cloud Redis 5.0 greatly optimizes the kernel, adds Stream, account management, audit logs, etc.

New data type: Stream (see Redis Streams).

Added account management.

Added log management: audit, runtime, slow logs.

Added snapshot‑based cache analysis.

New APIs for timers, cluster, dictionary modules.

RDB now includes LFU and LRU info.

Cluster manager moved from Ruby to C in redis‑cli.

New sorted‑set commands ZPOPMIN, ZPOPMAX, BZPOPMIN, BZPOPMAX.

Active Defragmentation upgraded to v2.

Enhanced HyperLogLog implementation.

Optimized memory statistics report.

Added HELP subcommand for many commands.

Improved performance for frequent client connect/disconnect.

Jemalloc upgraded to 5.1.

Added CLIENT ID and CLIENT UNBLOCK commands.

Added LOLWUT command.

Deprecated “slave” terminology (except for backward compatibility).

Network layer optimizations.

Lua related improvements.

Added dynamic HZ to balance idle CPU and latency.

Core code refactored and improved in many aspects.

Architecture Options

You need to choose according to business requirements:

Cluster Architecture – breaks Redis single‑thread bottleneck, suitable for large capacity and high performance.

Master‑Replica Architecture – provides high‑performance caching and high data reliability.

Read‑Write Separation Architecture – offers high availability, high performance, and flexibility for read‑heavy workloads, reducing operational costs.

2.1 Master‑Replica – Dual Replica

Uses master‑replica mode. The master serves requests; the replica provides HA. If the master fails, failover occurs within 30 seconds.

Reliability

Dual‑machine master‑replica across different physical machines; data persistence enabled; backup and clone capabilities.

Use Cases

Persistent storage with backup for reliable data.

Workloads with controllable QPS (< 100 k) can use single‑node Redis; higher QPS should use cluster.

Simple command workloads where CPU is the bottleneck; heavy sorting/computation should use cluster.

2.2 Master‑Replica – Single Replica

Suitable for pure cache scenarios without strict data reliability.

Use Cases

Pure cache business.

Single‑node Redis with manageable performance pressure (≈ 80 k QPS).

Workloads with few sorting/computation commands.

2.3 Cluster – Dual Replica

Breaks Redis single‑thread bottleneck; each shard uses master‑replica dual‑replica.

Proxy Mode

Cluster instances on local disks use proxy mode, providing a single connection address; the proxy forwards requests to shards, simplifying client development.

Direct Mode

Bypassing the proxy reduces network overhead and response time for latency‑sensitive workloads.

Prerequisite: use Jedis, PhpRedis or other clients that support Redis Cluster.

Clients not supporting Redis Cluster may fail to redirect requests.

Jedis supports Cluster via JedisCluster class (see Jedis docs).

See Redis official client list for more supported clients.

Example code for custom connection pool:

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, cannot exceed instance limit
        config.setMaxIdle(200);
        // max total connections
        config.setMaxTotal(300);
        config.setTestOnBorrow(false);
        config.setTestOnReturn(false);
        // direct access address
        String host = "r-bp1xxxxxxxxxxxx.redis.rds.aliyuncs.com";
        int port = 6379;
        // instance password
        String password = "xxxxx";
        Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();
        jedisClusterNode.add(new HostAndPort(host, port));
        JedisCluster jc = new JedisCluster(jedisClusterNode, DEFAULT_TIMEOUT, DEFAULT_TIMEOUT,
                DEFAULT_REDIRECTIONS, password, "clientName", config);
    }
}

2.4 Cluster – Single Replica

2.5 Read‑Write Separation

Designed for read‑heavy, write‑light scenarios, offering high availability, high performance, and flexible read‑write separation, consisting of master‑backup, read‑only, proxy, and HA components.

High Availability

Self‑developed HA system monitors node health and automatically promotes a new master if needed.

Proxy adjusts node weight and disables unhealthy read‑only nodes.

High Performance

Chain replication allows linear performance scaling by adding read‑only nodes, with source‑level optimizations for stable replication.

Use Cases

High read QPS workloads.

Standard Redis cannot handle large QPS for read‑heavy workloads; the read‑write separation version can increase QPS up to five times by adding read‑only nodes.

It is fully compatible with Redis protocol, enabling smooth migration from standard Redis or upgrade to read‑write separation.

Recommendations

If a read‑only node fails, requests are redirected to other nodes; if all read‑only nodes are down, requests go to the master, which may increase load.

Full synchronization may be triggered after HA failover, during which read‑only nodes return “-LOADING Redis is loading the dataset in memory”.