What’s New in Redis 6.0 and 5.0? A Deep Dive into Features and Deployment Options

It is recommended to use the newer engine version to access more features.

Redis 6.0 New Features

Module system adds multiple new APIs.

Supports SSL/TLS encryption.

Supports the new Redis protocol RESP3.

Server supports multi‑mode client caching.

Supports multithreaded I/O.

Diskless replication is supported in replicas.

Redis‑benchmark adds support for Redis cluster mode.

Systemd rewrite support.

Disque module support.

Redis 5.0 New Features

Significant kernel optimizations for higher stability.

New data type: Stream (see Redis Streams).

Account management features added.

Log management with audit, runtime, and slow logs.

Snapshot‑based cache analysis.

New APIs for Timers, Cluster, and Dictionary modules.

LFU and LRU information added to RDB.

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

Sorted Set commands ZPOPMIN, ZPOPMAX, BZPOPMIN, BZPOPMAX added.

Active Defragmentation upgraded to v2.

Enhanced HyperLogLog implementation.

Improved memory statistics reporting.

HELP sub‑command added to many commands.

Better performance for frequent client connect/disconnect.

Jemalloc upgraded to 5.1.

CLIENT ID and CLIENT UNBLOCK commands added.

LOLWUT command added for fun.

Deprecated the term "slave" (except where API compatibility requires).

Network layer optimizations.

Lua‑related improvements.

Dynamic HZ introduced to balance idle CPU usage and responsiveness.

Core code refactored and improved in many areas.

Architecture Choices

Cluster architecture easily breaks the single‑thread bottleneck, suitable for high‑capacity, high‑performance workloads.

Master‑replica architecture provides high performance caching and strong data reliability.

Read‑write separation architecture offers high availability, high performance, and flexible read‑write split for hotspot data and high‑concurrency reads, reducing operational costs.

2.1 Master‑Replica Architecture – Dual Replica

Uses a master‑replica mode where the master handles normal service requests and the replica provides HA. If the master fails, the system automatically switches to the replica within 30 seconds, ensuring smooth operation.

Reliability

Dual‑machine master‑replica setup with nodes on different physical machines; master serves external requests.

Data persistence is enabled by default; all data is persisted to disk.

Backup functionality allows rollback or cloning of instances to recover from accidental operations.

2.2 Master‑Replica Architecture – Single Replica

Suitable for pure cache scenarios without strict data reliability requirements, offering performance advantages.

Only one database node exists; if it fails, a new Redis process starts without data, and the application must re‑warm the cache.

Single‑replica does not provide data reliability; for sensitive workloads requiring high reliability, dual‑replica is recommended.

2.3 Cluster – Dual Replica

Breaks Redis’s single‑thread bottleneck, supporting large capacity and high performance. Each shard uses a master‑replica dual‑replica mode. Two connection modes are available: proxy and direct.

Proxy Mode

In proxy mode, a single connection address (domain name) is used; the proxy forwards client requests to the appropriate data shards, simplifying application development.

Direct Mode

If ultra‑low latency is required, direct mode bypasses the proxy, connecting directly to backend shards, reducing network overhead and response time.

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

Clients that do not support Redis Cluster may fail to redirect requests correctly.

Jedis supports Redis Cluster via the JedisCluster class (see Jedis documentation).

More supported clients can be found on the Redis official client list.

Custom Connection Pool Example (Java)

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();
        // Maximum idle connections, set according to business needs, cannot exceed instance limits
        config.setMaxIdle(200);
        // Maximum total connections, set according to business needs, cannot exceed instance limits
        config.setMaxTotal(300);
        config.setTestOnBorrow(false);
        config.setTestOnReturn(false);
        // Direct access 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);
    }
}

2.4 Cluster – Single Replica

Images illustrating the single‑replica cluster architecture are omitted for brevity.

2.5 Read‑Write Separation

Designed for read‑heavy, write‑light scenarios, providing high availability, high performance, and flexible read‑write split to handle hotspot data and high concurrent reads, thereby reducing operational costs. The architecture consists of master‑backup nodes, read‑only nodes, a proxy node, and a high‑availability system.

Key Characteristics

High availability: automatic health monitoring, automatic master failover, and automatic read‑only node recovery.

High performance: chain replication architecture allows linear performance scaling by adding read‑only nodes, with source‑level optimizations for replication.

Typical Use Cases

High read QPS workloads where standard Redis cannot sustain the load.

Scenarios requiring strict Redis protocol compatibility; read‑write separation is fully compatible and supports seamless migration from standard Redis.

Summary

If a read‑only node fails, requests are redirected to other nodes; if all read‑only nodes are unavailable, requests fall back to the master, which may increase load and latency.

Full synchronization may be triggered on a read‑only node after a high‑availability switch, during which the node returns the "-LOADING Redis is loading the dataset in memory" message.