### Redis Cluster
Main purpose:
> **Horizontal scaling + High Availability**
Data is distributed across multiple masters using hash slots.
```text
Redis Cluster
┌─────────┐
│ Master 1│
└─────────┘
slots 0-5000
┌─────────┐
│ Master 2│
└─────────┘
slots 5001-10000
┌─────────┐
│ Master 3│
└─────────┘
slots ...
```
Each master can have replicas.
### Remember:
```text
Sentinel → HA / automatic failover
Cluster → Sharding + HA
```
---
# 8. Sentinel does NOT store your Redis data
Very important.
```text
Redis Master
↓
Actual data
```
Sentinel:
```text
Sentinel
↓
Monitoring + coordination + failover
```
Sentinel doesn't act like another Redis database.
---
# 9. Why 3 Sentinels?
Suppose you have only:
```text
Sentinel 1
```
It says:
> Master is down.
But maybe Sentinel itself has a network problem.
With three:
```text
Sentinel 1 → Down
Sentinel 2 → Down
Sentinel 3 → Down
```
Now you have stronger agreement.
A common production setup is **3 or 5 Sentinels**, depending on availability requirements.
### Why odd numbers?
For quorum/majority decisions:
```text
3 → majority = 2
5 → majority = 3
```
This avoids ties more easily.
---
# 10. Java/Spring Boot Architecture
Your typical architecture could be:
```text
Spring Boot
|
Lettuce/Jedis
|
Redis Sentinel
/ | \
/ | \
↓ ↓ ↓
Sentinel1 Sentinel2 Sentinel3
|
Redis deployment
/ \
↓ ↓
Master Replica
```
Application doesn't need to know permanently:
```text
"Redis-B is master"
```
Sentinel handles master discovery.
---
# 11. Failure scenario — Interview Favorite ⭐
Interviewer:
> "Redis master suddenly goes down. What happens?"
Answer step-by-step:
```text
1. Sentinel monitors Redis nodes
↓
2. Sentinel detects master failure
↓
3. S_DOWN
↓
4. Other Sentinels confirm
↓
5. O_DOWN
↓
6. Sentinels elect a leader
↓
7. Leader selects suitable replica
↓
8. Replica is promoted
↓
9. New master announced
↓
10. Redis clients discover new master
```
That's the complete flow.
---
# 🔥 Sentinel vs Cluster — Memorize This
| Feature | Sentinel | Redis Cluster |
| ----------------------- | ------------------- | ------------- |
| Monitoring | ✅ | ✅ |
| Automatic failover | ✅ | ✅ |
| Replication | Uses Redis replicas | Uses replicas |
| Sharding | ❌ | ✅ |
| Horizontal data scaling | ❌ | ✅ |
| Multiple masters | ❌ | ✅ |
| Main purpose | HA | Scaling + HA |
---
# 🧠 Ramesh Memory Trick
Think of a company:
```text
Redis Master = CEO
Redis Replica = Deputy CEO
Sentinels = Board members
```
CEO dies:
```text
CEO ❌
↓
Board detects
↓
Board agrees
↓
Deputy promoted
↓
New CEO
```
That's **Redis Sentinel**.
### One-line interview answer:
> **"Redis Sentinel is a distributed monitoring and failover mechanism for Redis. It monitors master and replicas, detects failures, reaches quorum, elects a Sentinel leader, promotes an appropriate replica to master, and allows clients to discover the new master."**
For your **Spring Boot + Redis + Kubernetes architecture**, one additional point is important: **Sentinel and Kubernetes solve different layers of the problem**. Kubernetes can restart/reschedule Redis containers, while Sentinel provides Redis-aware master election and failover.
-------
No comments:
Post a Comment