Redis Engine Versions, New Features, and Deployment Architecture Options

The article surveys Redis engine versions and presents the new capabilities introduced in Redis 6.0 and Redis 5.0, then examines various deployment architectures suitable for production environments.

Redis 6.0 new features include a richer module API, SSL/TLS encryption, the RESP3 protocol, server‑side client caching, multithreaded I/O, diskless replication, benchmark support for cluster mode, Systemd rewrite, and the Disque module.

Redis 5.0 new features cover a major kernel optimization, the Stream data type, account management, audit and slow‑log facilities, snapshot‑based cache analysis, new timer, cluster and dictionary module APIs, LFU/LRU info in RDB, migration of the cluster manager to C code, new sorted‑set commands (ZPOPMIN/ZPOPMAX/BZPOPMIN/BZPOPMAX), upgraded active defragmentation, enhanced HyperLogLog, improved memory statistics, HELP sub‑command for many commands, better performance for frequent connect/disconnect cycles, Jemalloc 5.1, CLIENT ID/UNBLOCK commands, the LOLWUT command, deprecation of the “slave” term, network layer optimizations, Lua improvements, dynamic HZ, and extensive core code refactoring.

The article then outlines three main architecture patterns: cluster architecture for breaking the single‑thread bottleneck and handling large capacity; master‑replica (primary‑secondary) architecture with either double‑replica for high reliability or single‑replica for pure caching; and read‑write‑separation architecture for read‑heavy workloads, offering high availability, linear performance scaling, and cost‑effective operation.

In the double‑replica master‑replica model, the primary node serves traffic while a standby provides HA; automatic failover occurs within 30 seconds. Persistence is enabled by default, and backup/clone capabilities protect against accidental data loss.

The cluster double‑replica mode uses a master‑replica pair for each shard. Two connection modes are described: proxy mode , where a single endpoint forwards requests to shards, simplifying client code; and direct mode , which bypasses the proxy for lower latency when performance is critical. Diagrams illustrate both modes.

For developers using Java, the article provides a complete code example that creates a custom Jedis connection pool for a Redis cluster, sets idle and total connection limits, configures authentication, and initializes a JedisCluster instance.

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);
        // 最大连接数, 根据业务需要设置，不能超过实例规格规定的最大的连接数
        config.setMaxTotal(300);
        config.setTestOnBorrow(false);
        config.setTestOnReturn(false);
        // 开通直连访问时申请到的直连地址
        String host = "r-bp1xxxxxxxxxxxx.redis.rds.aliyuncs.com";
        int port = 6379;
        // 实例的密码
        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);
    }
}

Finally, the article recommends choosing the architecture that matches business requirements—cluster for high throughput, double‑replica master‑replica for data safety, or read‑write‑separation for read‑dominant workloads—and notes that the content is for learning and reference only.