# Redis Replication Made Simple: With Spring Boot Integration

---

Imagine it’s 3 AM. Your Redis server—yes, the one holding all your app’s session data—just crashed. Your team’s phones are buzzing. Users are locked out, and panic is rising.

What if I told you this nightmare could be avoided with a simple feature built right into Redis? Enter **Redis replication**—your built-in safeguard for data availability, read scaling, and peace of mind.

---

## 🔑 What Is Redis Replication?

At its core, **Redis replication** enables a single Redis instance (the **primary**) to automatically copy its data to one or more **replicas**.

* The **primary** handles all write operations.
    
* **Replicas** stay in sync and serve read requests, reducing the load on the primary.
    
* If the primary fails, replicas can quickly take over.
    

This fundamental setup lays the groundwork for high availability and scaling in Redis environments.

---

## ⚙️ How Does It Work?

Redis replication works in three key stages:

1. **Initial Sync:** A replica requests a full snapshot (RDB) from the primary, loads it, and applies any updates.
    
2. **Command Streaming:** Once synced, the replica continuously receives write commands from the primary to stay current.
    
3. **Partial Resync (PSYNC2):** If a replica temporarily disconnects, it resumes from where it left off using Redis’s backlog buffer—avoiding a full resync.
    

This process is **asynchronous**, which means replicas may lag slightly but offer high throughput.

---

## 🖥 Setting Up Replication (Primary + Two Replicas)

Here’s how to launch a simple master-replica setup locally:

```bash
# Start Primary
redis-server --port 6379

# Start Replica 1
redis-server --port 6380 --replicaof 127.0.0.1 6379

# Start Replica 2
redis-server --port 6381 --replicaof 127.0.0.1 6379
```

At this point, reads can be routed to replicas while writes continue to flow to the primary.

---

## 🆕 Chained Replication (Replica of a Replica)

Beyond basic replication, Redis supports **chained replication**, where a replica can act as a source for another replica.

### Why Use It?

* **Reduce primary load:** Only one replica pulls directly from the primary.
    
* **Regional optimization:** Place replicas closer to users while syncing through a nearer node.
    
* **Better bandwidth usage:** Ideal for distributed or high-latency networks.
    

Example:

```bash
# Primary
redis-server --port 6379

# Replica 1 (syncs from primary)
redis-server --port 6380 --replicaof 127.0.0.1 6379

# Replica 2 (syncs from Replica 1)
redis-server --port 6381 --replicaof 127.0.0.1 6380
```

---

## ✒Deployment Diagram

This diagram shows a primary node with two direct replicas and one chained replica.

```plaintext
								  +--------+
								  | Server |
								  +---+----+
									  |
									 WRITE
									  v
								  +--------+
								  | Master |
								  +---+----+
								  /        \
							 SYNC/          \SYNC
								v            v
						+-------+--+    +----+------+
						| Replica  |    |  Replica  |
						+----+-----+    +-----+-----+
							 |
						 CHAINED SYNC
							 v
						+----+-----+
						| Replica  |
						+----------+
```

---

## ⚡ Diskless Replication

To further speed up initial synchronization, enable **diskless replication**, which streams snapshots directly to replicas:

redis.conf (master)

```plaintext
repl-diskless-sync yes
repl-diskless-sync-delay 5
```

redis.conf (replica)

```plaintext
replicaof redis-master 6379
replica-read-only yes
repl-diskless-load on-empty-db
```

This avoids writing intermediate files to disk and is ideal for large datasets or high-performance environments.

---

## 🔧 Spring Boot with Redis Replicas

Let’s integrate this into a Spring Boot project for practical use.

### Dependency:

```xml
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
```

### Configuration:

```java
@Bean
public LettuceConnectionFactory redisConnectionFactory() {
    RedisStaticMasterReplicaConfiguration masterReplicaConfig =
            new RedisStaticMasterReplicaConfiguration("127.0.0.1", 6379);
    masterReplicaConfig.addNode("127.0.0.1", 6380);
    masterReplicaConfig.addNode("127.0.0.1", 6381);
    masterReplicaConfig.setPassword(RedisPassword.of("myRedisPass"));

    LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
            .readFrom(ReadFrom.ANY_REPLICA)
            .build();

    return new LettuceConnectionFactory(masterReplicaConfig, clientConfig);
}
```

This configuration connects Spring Boot to a primary and its replicas, preferring replica reads automatically.

---

## 🛠 Verifying Reads Are Hitting Replicas

To confirm that reads hit replicas rather than the primary:

### 1️⃣ Monitor Replica Activity

```bash
redis-cli -p 6380 MONITOR
```

Execute a read query and see it logged on the replica.

### 2️⃣ In Spring Boot

```java
@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Bean
public CommandLineRunner testRedis() {
    return args -> {
        ValueOperations<String, Object> ops = redisTemplate.opsForValue();
        ops.set("user:1", "Alice"); // Write -> Master
        String value = ops.get("user:1"); // Read -> Replica
        System.out.println("Read value (replica preferred): " + value);
    };
}
```

---

## ⚠️ Limitations of Replicas Alone

However, while replication improves resilience, it doesn’t guarantee full HA on its own.

* **No automatic failover:** Promotion must be done manually without Sentinel or Cluster.
    
* **Asynchronous replication:** Recent writes might be lost if the primary fails before syncing.
    
* **Single control point:** The primary remains the bottleneck for writes.
    

These gaps highlight why replication is essential but insufficient for full HA in production environments.

---

## ✅ Final Thoughts

Redis replication is a **simple yet powerful** way to protect against single points of failure, scale reads, and prepare for failover. Its nature—one primary continuously mirrored by one or more replicas—ensures that your data is **redundant, accessible, and performance-optimized**.

**Why use replicas?**

* Keep a live backup ready for emergencies.
    
* Reduce read load on the primary.
    
* Improve latency with geographically placed replicas.
    

**Key takeaway**: Replication is your **first step** toward high availability. Pair it with **Sentinel** for automatic failover or **Cluster** for sharding to achieve a **production-grade, fault-tolerant Redis deployment**.

---

## 🛠 Demo Project for Readers

I have created a **demo project** that showcases practical usage of Redis replica.

### Project Includes:

* **Docker**: Pre-configured Redis master & replicas using `docker-compose`.
    
* **Spring Boot**: Example backend service demonstrating Redis read/write splitting.
    

### 🔗 Access the Project

You can clone or explore the project from my repository :

```bash
git clone https://github.com/arata-x/redis-ha.git
cd redis-ha
```

---

## Additional Resources

* [Official Replication Documentation](https://redis.io/docs/latest/operate/oss_and_stack/management/replication/)
    
* [Spring Data Redis Reference Guide](https://docs.spring.io/spring-data/redis/docs/current/reference/html/)