Redis replication और high availability कैसे काम करते हैं?

Question

Accepted Answer

Redis **replication** (data की replica copies), **Redis Sentinel** (automatic failover monitoring), और **Redis Cluster** (sharding + replication) के माध्यम से **high availability** प्रदान करता है। इन्हें समझना production में Redis को reliably चलाने के लिए महत्वपूर्ण है।

## Replication — primary और replicas

```text
PRIMARY (master) → handles writes; asynchronously replicates data to replicas
REPLICAS (slaves) → copies of the primary's data; can serve READS (read scaling)

Write → Primary → async replication → Replicas (eventually consistent)
  ✓ Redundancy (replicas have copies) + read scaling (reads offloaded to replicas)
  ✗ Replication is ASYNC → a small lag; a failover could lose very recent writes
```

Replicas primary के data को asynchronously copy करते हैं — redundancy और read scaling प्रदान करते हुए (reads replicas पर जा सकते हैं), हालाँकि थोड़ी replication lag के साथ।

## Redis Sentinel — automatic failover

```text
Replication alone doesn't auto-recover if the PRIMARY fails. REDIS SENTINEL adds:
  → MONITORING — Sentinels watch the primary and replicas
  → AUTOMATIC FAILOVER — if the primary fails, Sentinels elect a replica as the new primary
  → SERVICE DISCOVERY — clients ask Sentinel for the current primary address
→ Sentinel provides high availability (auto-failover) for a non-clustered setup.
  (Run multiple Sentinels — a majority must agree — to avoid false failovers.)
```

**Sentinel** setup की monitoring करता है और **automatic failover** करता है (primary के fail होने पर एक replica को promote करना) — एक primary failure को outage के बजाय एक संक्षिप्त रुकावट में बदल देता है।

## Redis Cluster — sharding + HA

```text
REDIS CLUSTER → for scaling beyond one server's memory AND high availability:
  → SHARDS data across multiple primaries (each holds a subset via hash slots, 16384 total)
  → each primary has replicas (HA — a replica takes over if its primary fails)
  → scales horizontally (more memory/throughput) + built-in failover
→ Use Cluster when data exceeds one node's RAM or you need to scale writes.
```

## यह क्यों महत्वपूर्ण है

Redis replication और high availability को समझना **production में Redis को reliably चलाने** के लिए महत्वपूर्ण है, इसलिए यह production Redis deployments के लिए मूल्यवान senior-level ज्ञान है।

चूँकि Redis अक्सर महत्वपूर्ण data धारण करता है (caches जिनके खोने से load spikes होते हैं, sessions, queues), availability और redundancy सुनिश्चित करना मायने रखता है। **Replication** (replicas द्वारा primary को asynchronously copy करना) नींव प्रदान करता है — redundancy (replicas के पास copies हैं) और read scaling (reads को replicas पर offload करना) — हालाँकि इसकी **asynchronous प्रकृति** (थोड़ी lag, failover पर बहुत हाल के writes के संभावित नुकसान) को समझना consistency के बारे में तर्क करने के लिए महत्वपूर्ण है। **Redis Sentinel** non-clustered setups में high availability के लिए प्रमुख है: यह **monitoring और automatic failover** (primary के fail होने पर एक replica को promote करना) साथ ही service discovery जोड़ता है, एक primary failure को outage के बजाय एक संक्षिप्त रुकावट में बदल देता है — उन systems के लिए आवश्यक जिन्हें available रहना चाहिए (और majority agreement के लिए कई Sentinels चलाना false failovers से बचाता है)। **Redis Cluster** scaling और HA दोनों को संबोधित करता है: **कई primaries में data sharding** (hash slots के माध्यम से, एक server की memory और write throughput से परे scaling) failover के लिए replicas के साथ — आवश्यक जब data एक node की RAM से अधिक हो या writes को scale करना हो।

किसका उपयोग करना है यह समझना (एक single dataset के HA के लिए Sentinel, scale पर sharding + HA के लिए Cluster) सही operational निर्णय को दर्शाता है।

चूँकि production Redis को available होना चाहिए और scale करने की आवश्यकता हो सकती है, और चूँकि replication (redundancy/read scaling), Sentinel (automatic failover), और Cluster (sharding + HA) reliability और scale के लिए Redis के mechanisms हैं, Redis replication और high availability को समझना Redis को reliably deploy करने के लिए महत्वपूर्ण senior-level ज्ञान है, एक बार-बार महत्वपूर्ण production चिंता और एक विषय जो यह समझ दर्शाता है कि Redis को infrastructure के एक भरोसेमंद हिस्से के रूप में कैसे चलाया जाए न कि एक single point of failure के रूप में।