Choosing the Right Redis Deployment: Features, Architectures, and Best Practices

Redis Engine Versions

Redis 6.0 New Features

Extended module system APIs.

Native SSL/TLS encryption support.

RESP3 protocol implementation.

Server‑side client caching with multiple modes.

Multithreaded I/O for improved throughput.

Diskless replication for replicas.

Cluster mode added to redis-benchmark.

Systemd service file rewrite support.

Disque module compatibility.

Redis 5.0 New Features

Kernel optimizations for higher stability.

New data type: Streams (Redis Streams).

Account management APIs.

Audit, slow‑log and runtime log capabilities.

Snapshot‑based cache analysis.

New timer, cluster and dictionary module APIs.

LFU/LRU statistics stored in RDB files.

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

Sorted‑set commands: ZPOPMIN, ZPOPMAX, BZPOPMIN, BZPOPMAX.

Active Defragmentation v2.

Enhanced HyperLogLog implementation.

Improved memory statistics reporting. HELP subcommand for commands with many sub‑commands.

Optimized for frequent connect/disconnect cycles.

Jemalloc upgraded to 5.1.

New commands: CLIENT ID and CLIENT UNBLOCK.

Easter‑egg LOLWUT command.

Deprecated "slave" terminology (API‑compatible exceptions).

Network layer optimizations and dynamic HZ for balancing idle CPU usage and responsiveness.

Extensive core code refactoring and numerous enhancements.

Deployment Architecture Options

Choose an architecture based on business requirements such as throughput, data reliability, and read/write patterns.

Cluster architecture breaks the single‑thread bottleneck and suits high‑capacity, high‑performance workloads.

Master‑replica architecture offers strong data reliability with relatively simple command sets.

Read/write‑split architecture provides high availability and linear scaling for read‑heavy traffic.

1. Master‑Replica with Double Replica

Reliability: Two‑machine master‑replica across different physical hosts; automatic failover within ~30 seconds.

Persistence: Data persistence enabled by default; full disk storage and backup capabilities.

Use cases: Scenarios requiring durable storage, backup/restore, and strong data reliability.

Performance ceiling: Suitable for workloads up to ~100 k QPS; higher QPS should consider cluster mode.

Command profile: Simple command sets benefit from single‑thread performance; compute‑heavy workloads favor clustering.

2. Master‑Replica with Single Replica

Optimized for pure cache workloads where data durability is not required.

Single replica provides no data persistence; node failure requires data warm‑up.

Recommended for QPS below ~80 k and simple command sets.

3. Cluster with Double Replica (Sharded Cluster)

Each shard runs a master‑replica pair, allowing horizontal scaling.

Proxy mode: A single endpoint forwards requests to the appropriate shard, simplifying client configuration.

Direct mode: Clients connect directly to shard nodes, reducing latency at the cost of client‑side shard awareness.

4. Cluster with Single Replica

Similar to the double‑replica cluster but each shard has only a master node, offering higher write throughput at the expense of replica‑based durability.

5. Read/Write‑Split Architecture

High availability: Custom HA system monitors node health, auto‑promotes replicas, and restarts failed read‑only nodes.

High performance: Chain replication enables linear QPS growth by adding read‑only nodes; source‑level replication optimizations improve stability.

Typical scenarios: Read‑heavy workloads, hotspot data, and situations demanding protocol compatibility with standard Redis.

Operational notes: Deploy multiple read‑only nodes to avoid master overload; be aware that a read node restart triggers a full‑sync pause during which the node returns a -LOADING error.

Jedis Client Example for Direct Mode

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();
        config.setMaxIdle(200);               // adjust per business needs
        config.setMaxTotal(300);
        config.setTestOnBorrow(false);
        config.setTestOnReturn(false);

        String host = "r-bp1xxxxxxxxxxxx.redis.rds.aliyuncs.com"; // direct‑mode address
        int port = 6379;
        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);
    }
}

Clients that do not support Redis Cluster (e.g., older Jedis versions, some language drivers) may fail to redirect requests to the correct shard.

Supported Redis‑Cluster clients include JedisCluster (Jedis), PhpRedis, and others listed on the official Redis client page.