Redis ਉਤਪਾਦਨ ਵਿੱਚ ਉੱਚ ਉਪਲਬਧਤਾ: ਸੈਂਟੀਨੇਲ, ਕਲੱਸਟਰ, ਅਤੇ Kubernetes ਆਪਰੇਟਰ

Redis HA Helm ਮੁੱਲ

# values-redis-ha.yaml — Helm values for Redis HA on k3s/Longhorn
redis:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: 8Gi
    limits:
      cpu: "4"
      memory: 16Gi
  storage:
    persistentVolumeClaim:
      metadata:
        name: redis-data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 50Gi
        storageClassName: longhorn
  customConfig:
    maxmemory: "6gb"
    maxmemory-policy: "allkeys-lru"
    save: "900 1 300 10 60 10000"
    appendonly: "yes"
    appendfsync: "everysec"
    aof-use-rdb-preamble: "yes"
    repl-backlog-size: "256mb"
    tcp-keepalive: "60"
    timeout: "300"
    hz: "10"
    activedefrag: "yes"
  exporter:
    enabled: true
    image: oliver006/redis_exporter:latest

sentinel:
  replicas: 3
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 200m
      memory: 256Mi
  customConfig:
    down-after-milliseconds: "5000"
    failover-timeout: "60000"
    parallel-syncs: "1"

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app.kubernetes.io/component
              operator: In
              values:
                - redis
        topologyKey: kubernetes.io/hostname

ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਅਤੇ ਬੇਦਖਲੀ ਨੀਤੀਆਂ

Redis ਮੈਮੋਰੀ ਵਿੱਚ ਸਾਰਾ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਨੂੰ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਾਰਜਸ਼ੀਲ ਚਿੰਤਾ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ Redis ਸੰਰਚਿਤmaxmemoryਸੀਮਾ 'ਤੇ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਆਉਣ ਵਾਲੀਆਂ ਲਿਖਤ ਕਮਾਂਡਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ। ਬੇਦਖਲੀ ਨੀਤੀ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ।

# redis.conf — Memory management
maxmemory 6gb
maxmemory-policy allkeys-lru

# Available eviction policies:
# noeviction        — Return errors on writes when memory limit reached
# allkeys-lru       — Evict least recently used keys (general-purpose cache)
# allkeys-lfu       — Evict least frequently used keys (better for skewed access patterns)
# volatile-lru      — Evict LRU keys with TTL set
# volatile-lfu      — Evict LFU keys with TTL set
# volatile-ttl      — Evict keys with shortest TTL first
# allkeys-random    — Evict random keys
# volatile-random   — Evict random keys with TTL set

# Active defragmentation (Redis 4.0+)
activedefrag yes
active-defrag-enabled yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100
active-defrag-cycle-min 1
active-defrag-cycle-max 25
active-defrag-max-scan-fields 1000

# Memory usage monitoring
# redis-cli INFO memory
# Key metrics:
#   used_memory           — Total bytes allocated by Redis
#   used_memory_rss       — Resident set size (OS-level memory)
#   mem_fragmentation_ratio — RSS / used_memory (should be close to 1.0)
#   maxmemory             — Configured memory limit
#   evicted_keys          — Total keys evicted due to maxmemory

HA ਤੈਨਾਤੀਆਂ ਲਈ,maxmemoryਨੂੰ ਨੋਡ ਦੀ ਉਪਲਬਧ RAM ਦੇ ਲਗਭਗ 75% 'ਤੇ ਸੈੱਟ ਕਰੋ। ਬਾਕੀ 25% ਰਿਪਲੀਕੇਸ਼ਨ ਆਉਟਪੁੱਟ ਬਫਰ, AOF ਰੀਰਾਈਟ ਬਫਰ, RDB ਸਨੈਪਸ਼ਾਟ ਦੇ ਦੌਰਾਨ ਕਾਪੀ-ਆਨ-ਰਾਈਟ ਮੈਮੋਰੀ, ਅਤੇ OS ਓਵਰਹੈੱਡ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਦਾ ਹੈ। 16GB ਪੌਡ ਲਈ, ਅਧਿਕਤਮ ਮੈਮੋਰੀ ਨੂੰ 12GB 'ਤੇ ਸੈੱਟ ਕਰੋ। ਇੱਕ 64GB ਬੇਅਰ ਮੈਟਲ ਸਰਵਰ ਲਈ, ਇਸਨੂੰ 48GB 'ਤੇ ਸੈੱਟ ਕਰੋ।

TLS ਇਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ACLs

ਉਤਪਾਦਨ Redis ਤੈਨਾਤੀਆਂ ਨੂੰ TLS ਦੇ ਨਾਲ ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ Redis 6.0 ਵਿੱਚ ਪੇਸ਼ ਕੀਤੇ ACLs (ਐਕਸੈਸ ਕੰਟਰੋਲ ਲਿਸਟ) ਦੇ ਨਾਲ ਵਧੀਆ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

# redis.conf — TLS configuration
tls-port 6380
port 0                            # Disable non-TLS port entirely
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients optional         # Require client certificates (mutual TLS)
tls-replication yes               # Encrypt replication traffic
tls-cluster yes                   # Encrypt cluster bus traffic
tls-protocols "TLSv1.3"           # Only allow TLS 1.3

# ACL configuration (Redis 6.0+)
# user  on|off [>password] [~pattern] [+command|-command] [&channel]
user default off                  # Disable the default user
user admin on >strong_admin_pass ~* +@all
user appuser on >app_pass ~app:* ~session:* ~cache:* +@read +@write +@connection -@admin -@dangerous
user readonly on >readonly_pass ~* +@read +@connection -@write -@admin
user replicator on >repl_pass +psync +replconf +ping

# Load ACL from external file
aclfile /etc/redis/users.acl

ਪਬ/ਸਬ ਅਤੇ ਸਟ੍ਰੀਮਜ਼

Redis Pub/Sub ਅਤੇ ਸਟ੍ਰੀਮ HA ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਿਹਾਰ ਕਰਦੇ ਹਨ। ਭਰੋਸੇਯੋਗ ਇਵੈਂਟ-ਸੰਚਾਲਿਤ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਇਹਨਾਂ ਅੰਤਰਾਂ ਨੂੰ ਸਮਝਣਾ ਜ਼ਰੂਰੀ ਹੈ।

Pub/Subਸੁਨੇਹੇ ਫਾਇਰ-ਐਂਡ-ਫਰਗੇਟ ਹੁੰਦੇ ਹਨ — ਉਹ ਨਿਰੰਤਰ ਨਹੀਂ ਹੁੰਦੇ, ਨਕਲ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ, ਅਤੇ ਬਫਰ ਨਹੀਂ ਹੁੰਦੇ। ਸੈਂਟੀਨੇਲ-ਅਧਾਰਿਤ HA ਸੈੱਟਅੱਪ ਵਿੱਚ, ਮਾਸਟਰ ਨਾਲ ਜੁੜੇ ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਪਰ ਇੱਕ ਫੇਲਓਵਰ ਦੇ ਦੌਰਾਨ, ਨਵੇਂ ਮਾਸਟਰ ਨੂੰ ਪਿਛਲੀਆਂ ਗਾਹਕੀਆਂ ਦਾ ਕੋਈ ਗਿਆਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਗਾਹਕਾਂ ਨੂੰ ਮੁੜ ਕਨੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਗਾਹਕੀ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ। Redis ਕਲੱਸਟਰ ਦੇ ਨਾਲ, ਪਬ/ਸਬ ਸੁਨੇਹੇ ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਸਲਈ ਕਿਸੇ ਵੀ ਨੋਡ ਨਾਲ ਜੁੜੇ ਗਾਹਕ ਪ੍ਰਕਾਸ਼ਿਤ ਸੰਦੇਸ਼ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ (ਹਾਲਾਂਕਿ ਇਹ ਅੰਤਰ-ਨੋਡ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ)।

Redis ਸਟ੍ਰੀਮਜ਼ਇੱਕ ਸਥਾਈ, ਪ੍ਰਤੀਕ੍ਰਿਤ ਡਾਟਾ ਢਾਂਚਾ ਹੈ ਜੋ HA ਵਾਤਾਵਰਨ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਸੁਨੇਹਾ ਡਿਲੀਵਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਸਟ੍ਰੀਮ ਐਂਟਰੀਆਂ ਨੂੰ ਸਧਾਰਣ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿਧੀ ਦੁਆਰਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਫੇਲਓਵਰਾਂ ਤੋਂ ਬਚਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਘੱਟੋ-ਘੱਟ-ਇੱਕ ਵਾਰ ਡਿਲੀਵਰੀ ਸਿਮੈਨਟਿਕਸ ਦੇ ਨਾਲ ਉਪਭੋਗਤਾ ਸਮੂਹਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। HA ਮੈਸੇਜਿੰਗ ਲਈ, ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਪਬ/ਸਬ ਨਾਲੋਂ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

# Redis Streams with consumer groups — HA-safe message processing

# Create a stream and consumer group
XGROUP CREATE events:orders orders-processors $ MKSTREAM

# Produce events
XADD events:orders * action "order_placed" order_id "12345" amount "599.99"
XADD events:orders * action "order_placed" order_id "12346" amount "149.99"

# Consume events (in consumer group — at-least-once delivery)
XREADGROUP GROUP orders-processors worker-1 COUNT 10 BLOCK 5000 STREAMS events:orders >

# Acknowledge processed events
XACK events:orders orders-processors 1681234567890-0

# Check pending messages (unacknowledged)
XPENDING events:orders orders-processors - + 10

# Claim abandoned messages (from a dead consumer)
XAUTOCLAIM events:orders orders-processors worker-2 60000 0-0 COUNT 10

# Trim stream to prevent unbounded growth
XTRIM events:orders MAXLEN ~ 100000

HA

Redis ਮੋਡੀਊਲ

Redis ਮੋਡੀਊਲ Redis ਨੂੰ ਵਿਸ਼ੇਸ਼ ਡਾਟਾ ਢਾਂਚੇ ਅਤੇ ਕਾਰਜਸ਼ੀਲਤਾ ਨਾਲ ਵਿਸਤਾਰ ਕਰਦੇ ਹਨ। ਤਿੰਨ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ — RedisJSON, RediSearch, ਅਤੇ RedisTimeSeries — ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਸੈਂਟੀਨੇਲ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ HA ਤੈਨਾਤੀਆਂ ਵਿੱਚ ਖਾਸ ਵਿਚਾਰ ਹਨ।

# redis.conf — Loading modules
loadmodule /opt/redis-stack/lib/rejson.so
loadmodule /opt/redis-stack/lib/redisearch.so
loadmodule /opt/redis-stack/lib/redistimeseries.so

# Modules are replicated to replicas via the command stream
# Ensure the same modules are installed on all nodes (master + replicas)

# RedisJSON — store and query JSON documents
JSON.SET user:1001 $ '{"name":"Alice","email":"alice@example.com","orders":42}'
JSON.GET user:1001 $.name

# RediSearch — full-text search with indexing
FT.CREATE idx:users ON JSON PREFIX 1 user: SCHEMA $.name AS name TEXT $.email AS email TAG $.orders AS orders NUMERIC
FT.SEARCH idx:users "@name:Alice"

# RedisTimeSeries — time-series data
TS.CREATE metrics:cpu:node1 RETENTION 86400000 LABELS host node1 metric cpu
TS.ADD metrics:cpu:node1 * 73.5
TS.RANGE metrics:cpu:node1 - + AGGREGATION avg 60000

ਜਦੋਂ HA ਵਿੱਚ Redis ਸਟੈਕ (ਮੌਡਿਊਲ ਬੰਡਲ) ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਾਰੇ ਨੋਡਸ — ਮਾਸਟਰ ਅਤੇ ਰਿਪਲੀਕਾ — ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਮੋਡਿਊਲ ਸੰਸਕਰਣ ਸਥਾਪਤ ਹਨ। ਮੋਡੀਊਲ ਕਮਾਂਡਾਂ ਨੂੰ ਸਟੈਂਡਰਡ ਰੀਪਲੀਕੇਸ਼ਨ ਸਟ੍ਰੀਮ ਦੁਆਰਾ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਉਹਨਾਂ ਨੂੰ ਚਲਾਉਣ ਦੇ ਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇੱਕ ਫੇਲਓਵਰ ਤੋਂ ਬਾਅਦ, RediSearch ਸੂਚਕਾਂਕ ਪ੍ਰਮੋਟ ਕੀਤੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ 'ਤੇ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ ਅਤੇ ਤੁਰੰਤ ਪੁੱਛਗਿੱਛ ਕਰਦੇ ਹਨ।

HA

ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਅਤੇ ਕਲਾਇੰਟ ਕੌਂਫਿਗਰੇਸ਼ਨ

Redis HA ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਲਚਕੀਲੇਪਨ ਲਈ ਸਹੀ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ ਜ਼ਰੂਰੀ ਹੈ। ਕਨੈਕਸ਼ਨ ਪੂਲ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਦੇ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ, ਆਟੋਮੈਟਿਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਤਰਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਸ਼ਾਨਦਾਰ ਫੇਲਓਵਰ ਹੈਂਡਲਿੰਗ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹਨ।

# Node.js — ioredis connection pool with cluster mode
const Redis = require('ioredis');

// Cluster mode connection
const cluster = new Redis.Cluster(
  [
    { host: '10.0.1.10', port: 7000 },
    { host: '10.0.1.11', port: 7000 },
    { host: '10.0.1.12', port: 7000 }
  ],
  {
    redisOptions: {
      password: 'cluster_password',
      connectTimeout: 10000,
      maxRetriesPerRequest: 3
    },
    scaleReads: 'slave',           // Route reads to replicas
    clusterRetryStrategy(times) {
      return Math.min(times * 200, 5000);
    },
    slotsRefreshTimeout: 2000,
    slotsRefreshInterval: 5000,
    enableOfflineQueue: true,
    enableReadyCheck: true,
    natMap: {}                     // For NAT/port-forwarded environments
  }
);

cluster.on('error', (err) => console.error('Cluster error:', err));
cluster.on('node error', (err, address) => {
  console.error(`Node ${address} error:`, err);
});

# Python — redis-py connection pool with cluster mode
from redis.cluster import RedisCluster
from redis.backoff import ExponentialBackoff
from redis.retry import Retry

retry = Retry(ExponentialBackoff(cap=5, base=0.1), retries=5)

rc = RedisCluster(
    startup_nodes=[
        {"host": "10.0.1.10", "port": 7000},
        {"host": "10.0.1.11", "port": 7000},
        {"host": "10.0.1.12", "port": 7000}
    ],
    password="cluster_password",
    decode_responses=True,
    read_from_replicas=True,
    retry=retry,
    retry_on_timeout=True,
    socket_timeout=5,
    socket_connect_timeout=5,
    max_connections=50,
    health_check_interval=30
)

rc.set("key", "value")
print(rc.get("key"))

// Go — go-redis cluster client with connection pooling
package main

import (
    "context"
    "time"

    "github.com/redis/go-redis/v9"
)

func NewRedisCluster() *redis.ClusterClient {
    return redis.NewClusterClient(&redis.ClusterOptions{
        Addrs: []string{
            "10.0.1.10:7000",
            "10.0.1.11:7000",
            "10.0.1.12:7000",
        },
        Password:         "cluster_password",
        ReadOnly:         true,
        RouteRandomly:    true,
        RouteByLatency:   false,
        PoolSize:         50,
        MinIdleConns:     10,
        DialTimeout:      10 * time.Second,
        ReadTimeout:      5 * time.Second,
        WriteTimeout:     5 * time.Second,
        PoolTimeout:      10 * time.Second,
        MaxRetries:       5,
        MinRetryBackoff:  200 * time.Millisecond,
        MaxRetryBackoff:  5 * time.Second,
    })
}

ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਰਣਨੀਤੀਆਂ

HA ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਨਾਲ ਵੀ, ਨਿਯਮਤ ਬੈਕਅੱਪ ਆਫ਼ਤ ਰਿਕਵਰੀ, ਪਾਲਣਾ, ਅਤੇ ਲਾਜ਼ੀਕਲ ਗਲਤੀਆਂ (ਦੁਰਘਟਨਾਤਮਕ FLUSHALL, ਖਰਾਬ ਐਪਲੀਕੇਸ਼ਨ ਰਾਈਟਸ) ਤੋਂ ਸੁਰੱਖਿਆ ਲਈ ਜ਼ਰੂਰੀ ਹਨ। Redis ਬੈਕਅੱਪ RDB ਸਨੈਪਸ਼ਾਟ ਅਤੇ AOF ਫ਼ਾਈਲਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹਨ।

#!/bin/bash
# redis-backup.sh — Automated Redis backup script

REDIS_HOST="10.0.1.10"
REDIS_PORT="6379"
REDIS_PASS="strong_master_password"
BACKUP_DIR="/backups/redis"
S3_BUCKET="s3://redis-backups-prod"
RETENTION_DAYS=30
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p "$BACKUP_DIR"

# Trigger RDB snapshot on the master
redis-cli -h "$REDIS_HOST" -p "$REDIS_PORT" -a "$REDIS_PASS" BGSAVE

# Wait for background save to complete
while [ "$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS LASTSAVE)" = "$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS LASTSAVE)" ]; do
  sleep 1
done
sleep 2

# Copy the RDB file
RDB_FILE=$(redis-cli -h "$REDIS_HOST" -p "$REDIS_PORT" -a "$REDIS_PASS" CONFIG GET dir | tail -1)
cp "${RDB_FILE}/dump.rdb" "${BACKUP_DIR}/dump_${DATE}.rdb"

# Compress and upload to S3
gzip "${BACKUP_DIR}/dump_${DATE}.rdb"
aws s3 cp "${BACKUP_DIR}/dump_${DATE}.rdb.gz" "${S3_BUCKET}/daily/dump_${DATE}.rdb.gz" \
  --storage-class STANDARD_IA

# Cleanup old local backups
find "$BACKUP_DIR" -name "dump_*.rdb.gz" -mtime +$RETENTION_DAYS -delete

# Verify backup integrity
redis-check-rdb "${BACKUP_DIR}/dump_${DATE}.rdb.gz" && \
  echo "Backup verified: dump_${DATE}.rdb.gz" || \
  echo "ERROR: Backup verification failed!"

echo "Backup complete: ${BACKUP_DIR}/dump_${DATE}.rdb.gz"

# Restore from RDB backup
# 1. Stop Redis
systemctl stop redis

# 2. Replace the RDB file
gunzip /backups/redis/dump_20260412_030000.rdb.gz
cp /backups/redis/dump_20260412_030000.rdb /data/redis/dump.rdb
chown redis:redis /data/redis/dump.rdb

# 3. Disable AOF temporarily (if enabled) to prevent AOF overriding RDB on startup
redis-cli -a password CONFIG SET appendonly no

# 4. Start Redis (loads RDB)
systemctl start redis

# 5. Re-enable AOF and rewrite it from the loaded data
redis-cli -a password CONFIG SET appendonly yes
redis-cli -a password BGREWRITEAOF

ਨਿਗਰਾਨੀ

ਵਿਆਪਕ ਨਿਗਰਾਨੀ Redis HA ਲਈ ਸੰਚਾਲਨ ਉੱਤਮਤਾ ਦੀ ਨੀਂਹ ਹੈ। RedisINFOਕਮਾਂਡ ਦੁਆਰਾ ਅਮੀਰ ਅੰਦਰੂਨੀ ਮੈਟ੍ਰਿਕਸ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦਾ ਹੈ, ਜਿਸ ਨੂੰ Prometheus Redis ਨਿਰਯਾਤਕ Grafana ਡੈਸ਼ਬੋਰਡਾਂ ਅਤੇ ਚੇਤਾਵਨੀ ਲਈ ਸਮਾਂ-ਸੀਰੀਜ਼ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ।

# Key Redis INFO sections for HA monitoring
redis-cli -a password INFO replication
# role:master
# connected_slaves:2
# slave0:ip=10.0.1.11,port=6379,state=online,offset=1234567,lag=0
# slave1:ip=10.0.1.12,port=6379,state=online,offset=1234560,lag=1
# master_replid:abc123...
# master_repl_offset:1234567
# repl_backlog_size:268435456
# repl_backlog_first_byte_offset:1000000

redis-cli -a password INFO memory
# used_memory:6442450944
# used_memory_human:6.00G
# used_memory_rss:6879707136
# mem_fragmentation_ratio:1.07
# maxmemory:6442450944
# maxmemory_policy:allkeys-lru
# evicted_keys:12345

redis-cli -a password INFO stats
# total_connections_received:50000
# total_commands_processed:12345678
# instantaneous_ops_per_sec:85432
# keyspace_hits:11000000
# keyspace_misses:1345678
# expired_keys:500000
# evicted_keys:12345

redis-cli -a password INFO clients
# connected_clients:150
# blocked_clients:0
# maxclients:10000

# Prometheus Redis Exporter deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-exporter
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis-exporter
  template:
    metadata:
      labels:
        app: redis-exporter
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
    spec:
      containers:
        - name: redis-exporter
          image: oliver006/redis_exporter:latest
          args:
            - --redis.addr=redis://redis-ha-master:6379
            - --redis.password=$(REDIS_PASSWORD)
            - --include-system-metrics
            - --is-cluster
          env:
            - name: REDIS_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: redis-secret
                  key: password
          ports:
            - containerPort: 9121
              name: metrics
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

# PrometheusRule for Redis HA alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: redis-ha-alerts
  namespace: monitoring
spec:
  groups:
    - name: redis-availability
      rules:
        - alert: RedisDown
          expr: redis_up == 0
          for: 1m
          labels:
            severity: critical
          annotations:
            summary: "Redis instance {{ $labels.instance }} is down"

        - alert: RedisReplicaDisconnected
          expr: redis_connected_slaves < 2
          for: 2m
          labels:
            severity: warning
          annotations:
            summary: "Redis master has fewer than 2 connected replicas"

        - alert: RedisReplicationLagHigh
          expr: redis_replication_lag > 5
          for: 3m
          labels:
            severity: warning
          annotations:
            summary: "Redis replication lag exceeds 5 seconds on {{ $labels.instance }}"

        - alert: RedisMemoryUsageHigh
          expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.9
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Redis memory usage above 90% on {{ $labels.instance }}"

        - alert: RedisEvictionsHigh
          expr: rate(redis_evicted_keys_total[5m]) > 100
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Redis evicting keys at >100/s on {{ $labels.instance }}"

        - alert: RedisKeyspaceHitRateLow
          expr: redis_keyspace_hits_total / (redis_keyspace_hits_total + redis_keyspace_misses_total) < 0.8
          for: 10m
          labels:
            severity: info
          annotations:
            summary: "Redis cache hit rate below 80% on {{ $labels.instance }}"

        - alert: RedisSentinelDown
          expr: redis_sentinel_master_status != 1
          for: 1m
          labels:
            severity: critical
          annotations:
            summary: "Redis Sentinel reports master unhealthy"

    - name: redis-performance
      rules:
        - alert: RedisSlowlogGrowing
          expr: increase(redis_slowlog_length[5m]) > 10
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Redis slow log growing rapidly on {{ $labels.instance }}"

        - alert: RedisConnectionsNearLimit
          expr: redis_connected_clients / redis_config_maxclients > 0.8
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Redis connected clients above 80% of maxclients"

Dragonfly ਅਤੇ KeyDB: Redis-ਅਨੁਕੂਲ ਵਿਕਲਪ

ਜਦੋਂ ਕਿ Redis ਪ੍ਰਮੁੱਖ ਇਨ-ਮੈਮੋਰੀ ਡਾਟਾ ਸਟੋਰ ਹੈ, ਦੋ Redis-ਅਨੁਕੂਲ ਵਿਕਲਪਾਂ ਨੇ ਖਾਸ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ ਟ੍ਰੈਕਸ਼ਨ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ।

ਡਰੈਗਨਫਲਾਈ

Dragonfly ਇੱਕ ਆਧੁਨਿਕ, ਮਲਟੀ-ਥ੍ਰੈਡਡ Redis ਰਿਪਲੇਸਮੈਂਟ ਹੈ ਜਿਸਦਾ ਉਦੇਸ਼ ਸਾਰੇ ਉਪਲਬਧ CPU ਕੋਰਾਂ ਦਾ ਲਾਭ ਉਠਾਉਂਦੇ ਹੋਏ ਇੱਕ ਡ੍ਰੌਪ-ਇਨ ਰਿਪਲੇਸਮੈਂਟ ਹੋਣਾ ਹੈ। ਰਵਾਇਤੀ Redis ਕਮਾਂਡ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਸਿੰਗਲ-ਥ੍ਰੈੱਡਡ ਹੈ — ਡਰੈਗਨਫਲਾਈ ਮਲਟੀ-ਕੋਰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਉੱਚ ਥ੍ਰੁਪੁੱਟ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਮਲਟੀਪਲ ਥ੍ਰੈੱਡਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸ਼ੇਅਰ-ਨਥਿੰਗ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹ Redis ਪ੍ਰੋਟੋਕੋਲ, ਜ਼ਿਆਦਾਤਰ Redis ਕਮਾਂਡਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਿਨਾਂ ਐਪਲੀਕੇਸ਼ਨ ਬਦਲਾਅ ਦੇ Redis ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।

# Run Dragonfly as a Redis replacement
docker run -d --name dragonfly \
  -p 6379:6379 \
  -v /data/dragonfly:/data \
  docker.dragonflydb.io/dragonflydb/dragonfly \
  --maxmemory 12gb \
  --proactor_threads 8 \
  --dbfilename dump.rdb \
  --requirepass strong_password

# Dragonfly in Kubernetes
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: dragonfly
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: dragonfly
  template:
    metadata:
      labels:
        app: dragonfly
    spec:
      containers:
        - name: dragonfly
          image: docker.dragonflydb.io/dragonflydb/dragonfly:latest
          args:
            - --maxmemory=12gb
            - --proactor_threads=8
            - --requirepass=strong_password
            - --snapshot_cron=*/30 * * * *
          ports:
            - containerPort: 6379
          resources:
            requests:
              cpu: "4"
              memory: 16Gi
            limits:
              cpu: "8"
              memory: 16Gi
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: longhorn
        resources:
          requests:
            storage: 100Gi

ਡਰੈਗਨਫਲਾਈ ਦੇ ਮੁੱਖ ਫਾਇਦੇ: ਮਲਟੀ-ਥ੍ਰੈੱਡਡ (8 ਕੋਰ ਬਨਾਮ ਸਿੰਗਲ-ਥ੍ਰੈਡਡ Redis 'ਤੇ 25x ਥਰੂਪੁੱਟ), ਬਿਹਤਰ ਮੈਮੋਰੀ ਕੁਸ਼ਲਤਾ (Redis ਡਿਕਟ ਦੀ ਬਜਾਏ ਡੈਸ਼ ਹੈਸ਼ ਟੇਬਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ), ਫੋਰਕ() ਓਵਰਹੈੱਡ ਤੋਂ ਬਿਨਾਂ ਬਿਲਟ-ਇਨ ਸਨੈਪਸ਼ਾਟ, ਅਤੇ ਵੱਡੇ ਡੇਟਾਸੈਟਾਂ ਲਈ ਮੂਲ ਸਮਰਥਨ। ਹਾਲਾਂਕਿ, 2026 ਤੱਕ, ਡਰੈਗਨਫਲਾਈ ਦਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਮਰਥਨ ਅਜੇ ਵੀ ਪਰਿਪੱਕ ਹੋ ਰਿਹਾ ਹੈ - ਇਹ ਪ੍ਰਾਇਮਰੀ-ਰਿਪਲੀਕਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਪਰ ਇਸ ਵਿੱਚ ਅਜੇ ਤੱਕ ਸੈਂਟੀਨੇਲ-ਬਰਾਬਰ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਸਿਸਟਮ ਨਹੀਂ ਹੈ। HA ਲਈ, Kubernetes ਸਿਹਤ ਜਾਂਚਾਂ ਅਤੇ ਸਟੇਟਫੁਲਸੈੱਟ ਰੀਸਟਾਰਟ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਫੇਲਓਵਰ ਦੇ ਨਾਲ ਲੋਡ ਬੈਲੈਂਸਰ ਦੇ ਪਿੱਛੇ ਤੈਨਾਤ ਕਰੋ।

KeyDB

KeyDB Redis ਦਾ ਇੱਕ ਮਲਟੀ-ਥਰਿੱਡਡ ਫੋਰਕ ਹੈ ਜੋ Snap (Snapchat ਦੇ ਪਿੱਛੇ ਵਾਲੀ ਕੰਪਨੀ) ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ Redis ਦੇ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹੈ ਅਤੇ ਮਲਟੀ-ਥ੍ਰੈਡਿੰਗ, ਐਕਟਿਵ-ਐਕਟਿਵ ਰਿਪਲੀਕੇਸ਼ਨ (ਮਲਟੀ-ਮਾਸਟਰ), ਫਲੈਸ਼ ਸਟੋਰੇਜ ਟਾਇਰਿੰਗ, ਅਤੇ ਸਬ-ਕੀ ਮਿਆਦ ਪੁੱਗਦੀ ਹੈ। KeyDB ਦੀ ਐਕਟਿਵ-ਐਕਟਿਵ ਪ੍ਰਤੀਕ੍ਰਿਤੀ HA ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਦਿਲਚਸਪ ਹੈ - ਦੋ KeyDB ਉਦਾਹਰਨਾਂ ਇੱਕੋ ਸਮੇਂ ਲਿਖਤਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਦੂਜੇ ਨੂੰ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ, ਜ਼ੀਰੋ-ਡਾਊਨਟਾਈਮ ਫੇਲਓਵਰ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ।

# keydb.conf — Multi-threaded configuration with active replication
server-threads 4                  # Use 4 threads for command processing
bind 0.0.0.0
port 6379
requirepass strong_password
masterauth strong_password

# Active-active replication (multi-master)
active-replica yes
replicaof peer-host 6379          # Bidirectional replication

# On the peer node, configure the reverse:
# replicaof this-host 6379

# FLASH storage tiering (for datasets larger than RAM)
# storage-provider flash /mnt/flash-storage 100
# maxmemory 16gb
# Will keep hot data in RAM and spill cold data to SSD

# SubKey expiration (unique to KeyDB)
# Allows setting TTL on hash fields, not just top-level keys
# EXPIREMEMBER myhash field1 3600

KeyDB ਇੱਕ ਮਜ਼ਬੂਤ ਵਿਕਲਪ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਭੂਗੋਲਿਕ ਵੰਡ ਜਾਂ ਜ਼ੀਰੋ-ਡਾਊਨਟਾਈਮ ਰੱਖ-ਰਖਾਅ ਲਈ ਮਲਟੀ-ਮਾਸਟਰ ਰੀਪਲੀਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਿੰਗਲ-ਥ੍ਰੈੱਡਡ Redis ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ Dragonfly ਨਾਲੋਂ Redis ਕੋਡਬੇਸ ਦੇ ਨੇੜੇ ਰਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਉੱਚ ਥ੍ਰੁਪੁੱਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ

ਪਾਈਪਲਾਈਨਿੰਗ

ਪਾਈਪਲਾਈਨਿੰਗ ਇੱਕ ਸਿੰਗਲ ਨੈੱਟਵਰਕ ਰਾਉਂਡ-ਟ੍ਰਿਪ ਵਿੱਚ ਕਈ ਕਮਾਂਡਾਂ ਨੂੰ ਬੈਚ ਕਰਦੀ ਹੈ, ਬਲਕ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਲੇਟੈਂਸੀ ਨੂੰ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਘਟਾਉਂਦੀ ਹੈ। ਅਗਲੀ ਕਮਾਂਡ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਕਲਾਇੰਟ ਸਾਰੀਆਂ ਕਮਾਂਡਾਂ ਇੱਕੋ ਵਾਰ ਭੇਜਦਾ ਹੈ ਅਤੇ ਸਾਰੇ ਜਵਾਬ ਇਕੱਠੇ ਪੜ੍ਹਦਾ ਹੈ।

# Python — Pipelining with redis-py
import redis
import time

r = redis.Redis(host='10.0.1.10', port=6379, password='password', decode_responses=True)

# Without pipelining: 1000 round-trips
start = time.time()
for i in range(1000):
    r.set(f'key:{i}', f'value:{i}')
print(f'Without pipeline: {time.time() - start:.3f}s')

# With pipelining: 1 round-trip for 1000 commands
start = time.time()
pipe = r.pipeline(transaction=False)
for i in range(1000):
    pipe.set(f'key:{i}', f'value:{i}')
pipe.execute()
print(f'With pipeline: {time.time() - start:.3f}s')
# Typically 5-10x faster

ਲੁਆ ਸਕ੍ਰਿਪਟਿੰਗ

ਲੂਆ ਸਕ੍ਰਿਪਟਾਂ Redis ਸਰਵਰ 'ਤੇ ਐਟਮਿਕ ਤੌਰ 'ਤੇ ਐਗਜ਼ੀਕਿਊਟ ਕਰਦੀਆਂ ਹਨ, ਗੁੰਝਲਦਾਰ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਰਾਉਂਡ-ਟਰਿੱਪਾਂ ਨੂੰ ਖਤਮ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਗਾਰੰਟੀ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਸਕ੍ਰਿਪਟ ਦੇ ਓਪਰੇਸ਼ਨਾਂ ਵਿਚਕਾਰ ਕੋਈ ਹੋਰ ਕਮਾਂਡ ਨਹੀਂ ਚਲਾਉਂਦੀ ਹੈ। Redis ਕਲੱਸਟਰ ਵਿੱਚ, ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਲੁਆ ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਐਕਸੈਸ ਕੀਤੀਆਂ ਸਾਰੀਆਂ ਕੁੰਜੀਆਂ ਹੈਸ਼ ਟੈਗਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕੋ ਹੈਸ਼ ਸਲਾਟ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ।

# Lua script for atomic rate limiting
# KEYS[1] = rate limit key
# ARGV[1] = max requests
# ARGV[2] = window in seconds
local current = redis.call('INCR', KEYS[1])
if current == 1 then
    redis.call('EXPIRE', KEYS[1], ARGV[2])
end
if current > tonumber(ARGV[1]) then
    return 0  -- Rate limited
end
return 1  -- Allowed

# Load and execute
redis-cli -a password EVAL "\
  local current = redis.call('INCR', KEYS[1]) \
  if current == 1 then redis.call('EXPIRE', KEYS[1], ARGV[2]) end \
  if current > tonumber(ARGV[1]) then return 0 end \
  return 1" 1 ratelimit:user:123 100 60

ਮੈਮੋਰੀ ਓਪਟੀਮਾਈਜੇਸ਼ਨ

# redis.conf — Memory optimisation settings

# Use ziplist encoding for small hashes, lists, sorted sets
hash-max-listpack-entries 128
hash-max-listpack-value 64
list-max-listpack-size -2          # 8KB per node
zset-max-listpack-entries 128
zset-max-listpack-value 64
set-max-intset-entries 512

# Lazy freeing (avoid blocking on large key deletion)
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
lazyfree-lazy-user-del yes
lazyfree-lazy-user-flush yes

# jemalloc tuning
# MALLOC_CONF="background_thread:true,dirty_decay_ms:5000,muzzy_decay_ms:5000"

# Analyse memory usage
redis-cli -a password MEMORY DOCTOR
redis-cli -a password MEMORY STATS
redis-cli -a password --bigkeys
redis-cli -a password --memkeys

ਆਮ ਅਸਫਲਤਾ ਦੇ ਦ੍ਰਿਸ਼ ਅਤੇ ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ

ਦ੍ਰਿਸ਼ 1: ਮਾਸਟਰ ਫੇਲ, ਸੈਂਟੀਨੇਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ

# Diagnosis
redis-cli -p 26379 SENTINEL master mymaster
# Check: flags should show 's_down' or 'o_down' if master is unreachable

redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# Returns the current master address (should be the promoted replica)

# Check Sentinel logs for failover events
tail -f /var/log/redis/sentinel.log
# Look for: +sdown, +odown, +try-failover, +elected-leader,
#           +failover-state-select-slave, +selected-slave,
#           +failover-state-send-slaveof-noone, +failover-end

ਦ੍ਰਿਸ਼ 2: ਦੋ ਮਾਸਟਰਾਂ ਦੇ ਨਾਲ ਸਪਲਿਟ-ਬ੍ਰੇਨ

# Diagnosis: check if min-replicas-to-write is configured
redis-cli -a password CONFIG GET min-replicas-to-write
redis-cli -a password CONFIG GET min-replicas-max-lag

# Prevention: configure min-replicas on all masters
redis-cli -a password CONFIG SET min-replicas-to-write 1
redis-cli -a password CONFIG SET min-replicas-max-lag 10

# If split-brain occurred: identify the stale master
# Compare replication offsets — the master with the higher offset has more data
redis-cli -h master1-ip -a password INFO replication | grep master_repl_offset
redis-cli -h master2-ip -a password INFO replication | grep master_repl_offset

# Force the stale master to become a replica
redis-cli -h stale-master-ip -a password REPLICAOF correct-master-ip 6379

ਦ੍ਰਿਸ਼ 3: ਨੈੱਟਵਰਕ ਭਾਗ

# Diagnosis: check replication backlog
redis-cli -a password INFO replication | grep repl_backlog
# If repl_backlog_first_byte_offset is ahead of replica's offset, full sync triggers

# Prevention: increase backlog size
redis-cli -a password CONFIG SET repl-backlog-size 512mb

# Monitor for full syncs
redis-cli -a password INFO stats | grep sync_full
redis-cli -a password INFO stats | grep sync_partial_ok
redis-cli -a password INFO stats | grep sync_partial_err

ਦ੍ਰਿਸ਼ 4: ਮੈਮੋਰੀ ਥਕਾਵਟ ਅਤੇ OOM ਕਿਲ

# Diagnosis
redis-cli -a password INFO memory
# Check: used_memory vs maxmemory, mem_fragmentation_ratio

redis-cli -a password MEMORY DOCTOR
# Returns advice on memory issues

# Prevention: set proper maxmemory and eviction
redis-cli -a password CONFIG SET maxmemory 12gb
redis-cli -a password CONFIG SET maxmemory-policy allkeys-lru

# Find large keys consuming memory
redis-cli -a password --bigkeys
redis-cli -a password --memkeys --memkeys-samples 100

# Emergency: manually evict keys
redis-cli -a password SCAN 0 COUNT 1000 TYPE string
# Identify and DEL unnecessary large keys

ਦ੍ਰਿਸ਼ 5: ਹੌਲੀ ਕਮਾਂਡਾਂ ਬਲਾਕਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ

# Diagnosis: check slowlog
redis-cli -a password SLOWLOG GET 20
redis-cli -a password SLOWLOG LEN

# Check for blocking commands
redis-cli -a password CLIENT LIST | grep -E 'cmd=(keys|sort|smembers)'

# Prevention: configure slowlog threshold
redis-cli -a password CONFIG SET slowlog-log-slower-than 10000   # 10ms
redis-cli -a password CONFIG SET slowlog-max-len 256

# Rename dangerous commands
rename-command KEYS ""              # Disable KEYS entirely
rename-command FLUSHALL ""          # Disable FLUSHALL
rename-command FLUSHDB ""           # Disable FLUSHDB
rename-command DEBUG ""             # Disable DEBUG

ਸਮਰੱਥਾ ਯੋਜਨਾ ਅਤੇ ਸਕੇਲਿੰਗ ਰਣਨੀਤੀਆਂ

ਸਮਰੱਥਾ ਯੋਜਨਾ ਵਿੱਚ ਮਾਸਟਰ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੋਡਾਂ ਵਿੱਚ ਮੈਮੋਰੀ ਲੋੜਾਂ, ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ, ਅਤੇ CPU ਉਪਯੋਗਤਾ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਸ਼ਾਮਲ ਹੈ। ਆਲੇ ਦੁਆਲੇ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਲਈ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਹਨ ਡੈਟਾਸੈੱਟ ਆਕਾਰ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਓਪਰੇਸ਼ਨ, ਔਸਤ ਕੁੰਜੀ/ਮੁੱਲ ਦਾ ਆਕਾਰ, ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਓਵਰਹੈੱਡ।

# Capacity estimation formulas

# Memory per node:
#   Base dataset size (use redis-cli DBSIZE and MEMORY USAGE on a sample)
#   + Replication output buffer: ~64MB per replica
#   + AOF rewrite buffer: ~64MB during rewrites
#   + Copy-on-write overhead during BGSAVE: up to 2x during heavy writes
#   + Client output buffers: ~1KB per client
#   + OS overhead: ~1-2GB
#   Rule of thumb: maxmemory = 75% of available RAM

# Network bandwidth:
#   Replication: write_throughput_bytes * num_replicas
#   Client traffic: ops_per_sec * avg_response_size
#   Full sync: dataset_size (one-time during replica bootstrap or failover)

# Example sizing for 20GB dataset, 100K ops/sec:
#   RAM per node: 20GB data + 4GB buffers + 2GB OS = 26GB -> 32GB node (75% = 24GB maxmemory)
#   CPU: 1 core handles ~100K ops/sec for simple commands (GET/SET)
#   Network: 100K ops * 1KB avg = 100MB/s client + 50MB/s replication = 150MB/s per master

# Scaling decision tree:
#   Need more read throughput? -> Add replicas (up to 5 per master)
#   Need more write throughput? -> Redis Cluster (add shards)
#   Need more memory? -> Redis Cluster (distribute dataset across shards)
#   Need lower latency? -> Reduce network hops (co-locate, use unix sockets)
#   Need global distribution? -> Multi-region replication or Redis Enterprise Active-Active

ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ

# Add shards to an existing Redis Cluster

# 1. Start new Redis nodes
redis-server /etc/redis/new-master.conf
redis-server /etc/redis/new-replica.conf

# 2. Add the new master to the cluster
redis-cli --cluster add-node new-master:7000 existing-node:7000 -a password

# 3. Add the new replica to follow the new master
redis-cli --cluster add-node new-replica:7000 existing-node:7000 \
  --cluster-slave --cluster-master-id NEW_MASTER_ID -a password

# 4. Reshard slots to the new master
redis-cli --cluster reshard existing-node:7000 \
  --cluster-from all --cluster-to NEW_MASTER_ID \
  --cluster-slots 4096 --cluster-yes -a password

# 5. Verify the new slot distribution
redis-cli -c -h existing-node -p 7000 -a password CLUSTER SLOTS

# Remove a shard (scale down)
# 1. Reshard all slots away from the node
redis-cli --cluster reshard existing-node:7000 \
  --cluster-from REMOVING_NODE_ID --cluster-to TARGET_NODE_ID \
  --cluster-slots 5461 --cluster-yes -a password

# 2. Remove the empty node
redis-cli --cluster del-node existing-node:7000 REMOVING_NODE_ID -a password

ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਵਿਚਾਰ

# When to scale vertically vs horizontally:

# Scale UP (bigger instances) when:
#   - Dataset fits in single-node memory
#   - Workload uses multi-key operations (MGET, SUNION, Lua across keys)
#   - Operational simplicity is more important than cost efficiency
#   - Using Redis modules that don't support Cluster mode well

# Scale OUT (more shards) when:
#   - Dataset exceeds single-node memory
#   - Write throughput exceeds single-thread capacity (~200K ops/sec)
#   - You need per-shard isolation for multi-tenant workloads
#   - Cost per GB of RAM is a concern (many smaller nodes vs few large ones)

# Cloud instance recommendations:
# AWS:   cache.r7g.xlarge (4 vCPU, 26GB) to cache.r7g.16xlarge (64 vCPU, 419GB)
# Azure: P1 (6GB) to P5 (120GB) per shard
# GCP:   5GB to 300GB per instance (Memorystore Standard)

# Bare metal:
#   CPU: 2-4 cores dedicated to Redis (single-threaded, but background tasks use extra cores)
#   RAM: 32-128GB per node (NVMe for swap-as-last-resort)
#   Network: 10Gbps minimum, 25Gbps for large datasets
#   Storage: NVMe SSD for AOF/RDB persistence (IOPS matters for fsync)

ਸਿੱਟਾ

Redis ਉੱਚ ਉਪਲਬਧਤਾ ਇੱਕ ਸਿੰਗਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿਕਲਪ ਨਹੀਂ ਹੈ - ਇਹ ਇੱਕ ਵਿਆਪਕ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਹੈ ਜੋ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਟੋਪੋਲੋਜੀ, ਅਸਫਲਤਾ ਖੋਜ, ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ, ਕਲਾਇੰਟ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਸਥਿਰਤਾ ਰਣਨੀਤੀ, ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ, ਸੁਰੱਖਿਆ, ਨਿਗਰਾਨੀ, ਅਤੇ ਸੰਚਾਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਫੈਲਾਉਂਦਾ ਹੈ। ਸਹੀ HA ਆਰਕੀਟੈਕਚਰ ਤੁਹਾਡੀਆਂ ਖਾਸ ਲੋੜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ,Redis ਸੈਂਟੀਨੇਲਇੱਕ ਮਾਸਟਰ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਵਾਲੇ ਤਿੰਨ ਸੈਂਟੀਨੇਲ ਉਦਾਹਰਨਾਂ ਅਤੇ ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ 30 ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਵਿੱਚ ਆਟੋਮੈਟਿਕ ਫੇਲਓਵਰ ਦੇ ਨਾਲ ਇੱਕ ਸਾਬਤ, ਲੜਾਈ-ਜਾਂਚ HA ਹੱਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੰਗਲ ਮਾਸਟਰ ਦੇ ਥ੍ਰਰੂਪੁਟ ਜਾਂ ਮੈਮੋਰੀ ਸਮਰੱਥਾ ਤੋਂ ਪਰੇ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂRedis ਕਲੱਸਟਰਬਿਲਟ-ਇਨ ਫੇਲਓਵਰ ਪ੍ਰਤੀ ਸ਼ਾਰਡ ਬਣਾਏ ਰੱਖਦੇ ਹੋਏ ਕਈ ਸ਼ਾਰਡਾਂ ਵਿੱਚ ਡੇਟਾਸੈਟ ਨੂੰ ਵੰਡਦਾ ਹੈ। Kubernetes ਵਾਤਾਵਰਣਾਂ ਲਈ,SpotahomeਅਤੇOpsTreeਵਰਗੇ ਓਪਰੇਟਰ ਸੰਚਾਲਨਤਮਿਕ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਘੋਸ਼ਣਾਤਮਕ CRDs ਵਿੱਚ ਏਨਕੋਡ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿRedis Enterpriseਐਕਟਿਵ-ਰੇਪਿਊਲ ਸਪੋਰਟ ਅਤੇ ਐਕਟਿਵ-ਮੋਡਲੀਕੇਸ਼ਨ ਸਪੋਰਟ ਦੇ ਨਾਲ ਸਭ ਤੋਂ ਵੱਧ ਵਿਸ਼ੇਸ਼ਤਾ-ਅਮੀਰ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।