Databases 12 min read

Redis Architecture Options and Deployment Guide

This article reviews Redis's latest features and compares various deployment architectures—including single‑replica, dual‑replica, cluster, and read‑write‑separation modes—detailing their reliability, performance characteristics, suitable use cases, and provides a Java Jedis example for configuring a direct‑connect cluster.

Top Architect
Top Architect
Top Architect
Redis Architecture Options and Deployment Guide

The author, a senior architect, shares a comprehensive overview of Redis deployment options after researching multiple Redis deployment patterns for production environments.

Redis 6.0 New Features

New module system APIs

SSL/TLS encryption support

RESP3 protocol

Client‑side caching in multiple modes

Multithreaded I/O

Diskless replication for replicas

Redis‑benchmark supports cluster mode

Systemd rewrite support

Disque module support

Redis 5.0 New Features

Kernel optimizations, stable operation

Streams data type

Account management

Audit, slow, and operation logs

Snapshot‑based cache analysis

New Timers, Cluster, Dictionary module APIs

LFU/LRU info in RDB

Cluster manager moved to C implementation

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

CLIENT ID and CLIENT UNBLOCK commands

LOLWUT command

Deprecation of the term "slave" (except for backward compatibility)

Network layer optimizations

Lua improvements

Dynamic HZ for balancing idle CPU usage

Core code refactoring and numerous improvements

Architecture Choices

Depending on business needs, choose among cluster, master‑replica, or read‑write‑separation architectures.

2.1 Master‑Replica (Dual‑Replica)

Provides high availability with automatic failover within 30 seconds; data persistence and backup are enabled by default.

2.2 Master‑Replica (Single‑Replica)

Suitable for pure cache scenarios without data reliability requirements; a node failure triggers a new Redis process and requires application warm‑up.

2.3 Cluster (Dual‑Replica)

Breaks Redis's single‑thread bottleneck using a sharded cluster where each shard runs a master‑replica pair. Supports both proxy and direct‑connect modes.

Proxy Mode

All client requests go through a single proxy address, simplifying development but adding a slight latency overhead.

Direct‑Connect Mode

Clients connect directly to shard nodes, reducing network overhead and response time; requires a Redis‑Cluster‑aware client such as Jedis.

2.4 Cluster (Single‑Replica)

Illustrated with diagrams; similar to dual‑replica but without replica redundancy.

2.5 Read‑Write‑Separation

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

Key Characteristics

High Availability : Automatic monitoring, failover, and node replacement.

High Performance : Chain replication allows linear performance growth with more read‑only nodes.

Use Cases

Ideal for scenarios with high read QPS, strict Redis protocol compatibility, or when migrating from standard Redis to a read‑write‑separated deployment.

Recommendations & Notices

If a read‑only node fails, traffic is rerouted to other nodes; if all read‑only nodes are down, traffic goes to the master, potentially increasing load.

Full synchronization may occur after a failover, during which the node returns a “‑LOADING” message.

Java Jedis Direct‑Connect Example

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 needs
        config.setMaxIdle(200);
        // Max total connections, set according to business needs
        config.setMaxTotal(300);
        config.setTestOnBorrow(false);
        config.setTestOnReturn(false);

        // Direct‑connect 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);
    }
}
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Javaarchitecturedatabasehigh availabilityredisJedisCluster
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.