Redis 6.0 & 5.0 New Features, Architecture Options, and Java Client Code Example

Author: 小热爱 (source: juejin.cn/post/6955355807231770631)

Redis 6.0 New Features

Module system adds multiple APIs.

Supports SSL/TLS encryption.

Introduces RESP3 protocol.

Server supports multi‑mode client caching.

Multi‑threaded I/O support.

Diskless replication in replicas.

Redis‑benchmark adds cluster mode.

Systemd rewrite support.

Disque module support.

Redis 5.0 New Features

Optimized kernel for stability; adds Stream, account management, audit logs.

New data type: Stream.

Account management feature.

Log management for audit, runtime, and slow logs.

Snapshot‑based cache analysis.

New APIs for Timers, Cluster, Dictionary modules.

LFU and LRU info in RDB.

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

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.

New commands CLIENT ID and CLIENT UNBLOCK.

LOLWUT command.

Deprecated "slave" terminology (except when API compatibility required).

Network layer optimizations.

Lua improvements.

Dynamic HZ for balancing idle CPU and responsiveness.

Core code refactoring and enhancements.

Architecture Choices

Choose based on business needs:

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

Master‑replica architecture provides high performance and data reliability.

Read‑write split architecture offers high availability, high performance, and flexibility for hot‑data and high‑concurrency reads, reducing operational costs.

2.1 Master‑Replica (Dual‑Replica)

The master handles daily traffic while the replica provides HA; automatic failover occurs within 30 seconds.

2.2 Master‑Replica (Single‑Replica)

Suitable for pure cache scenarios without strict data reliability; on failure a new Redis process starts without data, requiring cache warm‑up.

2.3 Cluster (Dual‑Replica)

Cluster mode uses a master‑replica pair per shard, supporting both proxy and direct connection modes.

2.4 Cluster (Single‑Replica)

Illustrated with diagrams (images omitted).

2.5 Read‑Write Split

Designed for read‑heavy, write‑light workloads, offering high availability, high performance, and linear scaling by adding read‑only nodes.

Code Example – Custom Jedis Connection Pool

import redis.clients.jedis.*;</code><code>import java.util.HashSet;</code><code>import java.util.Set;</code><code>public class main {</code><code>    private static final int DEFAULT_TIMEOUT = 2000;</code><code>    private static final int DEFAULT_REDIRECTIONS = 5;</code><code>    private static final JedisPoolConfig DEFAULT_CONFIG = new JedisPoolConfig();</code><code>    public static void main(String args[]) {</code><code>        JedisPoolConfig config = new JedisPoolConfig();</code><code>        // Max idle connections</code><code>        config.setMaxIdle(200);</code><code>        // Max total connections</code><code>        config.setMaxTotal(300);</code><code>        config.setTestOnBorrow(false);</code><code>        config.setTestOnReturn(false);</code><code>        String host = "r-bp1xxxxxxxxxxxx.redis.rds.aliyuncs.com";</code><code>        int port = 6379;</code><code>        String password = "xxxxx";</code><code>        Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();</code><code>        jedisClusterNode.add(new HostAndPort(host, port));</code><code>        JedisCluster jc = new JedisCluster(jedisClusterNode, DEFAULT_TIMEOUT, DEFAULT_TIMEOUT, DEFAULT_REDIRECTIONS, password, "clientName", config);</code><code>    }</code><code>}

The code demonstrates how to configure a Jedis connection pool and create a JedisCluster instance for direct access to a Redis cluster.