Redis ความพร้อมใช้งานสูงในการผลิต: ตัวดำเนินการ Sentinel, Cluster และ Kubernetes

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เป็นประมาณ 75% ของ RAM ที่พร้อมใช้งานของโหนด ส่วนที่เหลืออีก 25% รองรับบัฟเฟอร์เอาต์พุตการจำลอง, บัฟเฟอร์การเขียนซ้ำ AOF, หน่วยความจำการคัดลอกเมื่อเขียนระหว่างสแน็ปช็อต RDB และโอเวอร์เฮดของระบบปฏิบัติการ สำหรับพ็อดขนาด 16GB ให้ตั้งค่าหน่วยความจำสูงสุดเป็น 12GB สำหรับเซิร์ฟเวอร์ Bare Metal ขนาด 64GB ให้ตั้งค่าเป็น 48GB

TLS และ ACL

การผลิต Redis จะต้องเข้ารหัสข้อมูลระหว่างทางด้วย TLS และบังคับใช้การควบคุมการเข้าถึงแบบละเอียดด้วย ACL (รายการควบคุมการเข้าถึง) ที่นำมาใช้ใน Redis 6.0

# 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

Pub/Sub และสตรีมในการตั้งค่า HA

Redis Pub/Sub และ Streams มีพฤติกรรมแตกต่างออกไปในการกำหนดค่า HA การทำความเข้าใจความแตกต่างเหล่านี้ถือเป็นสิ่งสำคัญสำหรับการสร้างระบบที่ขับเคลื่อนด้วยเหตุการณ์ที่เชื่อถือได้

Pub/Subเป็นแบบ fire-and-forget — ข้อความเหล่านั้นจะไม่คงอยู่ ไม่จำลองแบบ และไม่ถูกบัฟเฟอร์ ในการตั้งค่า HA ที่ใช้ Sentinel สมาชิกที่เชื่อมต่อกับระบบหลักจะได้รับข้อความตามปกติ แต่ในระหว่างการเกิดข้อผิดพลาด สมาชิกหลักรายใหม่จะไม่มีความรู้เกี่ยวกับการสมัครสมาชิกก่อนหน้านี้ ลูกค้าจะต้องสมัครสมาชิกใหม่หลังจากเชื่อมต่อใหม่ ด้วยคลัสเตอร์ Redis ข้อความ Pub/Sub จะถูกถ่ายทอดไปยังโหนดทั้งหมดในคลัสเตอร์ ดังนั้นสมาชิกที่เชื่อมต่อกับโหนดใดๆ จะได้รับข้อความที่เผยแพร่ (แม้ว่าจะสร้างการรับส่งข้อมูลระหว่างโหนดก็ตาม)

Redis สตรีมเป็นโครงสร้างข้อมูลที่ทำซ้ำอย่างต่อเนื่อง ซึ่งให้การส่งข้อความที่เชื่อถือได้ในสภาพแวดล้อม HA รายการสตรีมจะถูกจำลองแบบเป็นแบบจำลองผ่านกลไกการจำลองแบบปกติ อยู่รอดจากการเฟลโอเวอร์ และสนับสนุนกลุ่มผู้บริโภคด้วยซีแมนทิกส์การจัดส่งอย่างน้อยหนึ่งครั้ง สำหรับการรับส่งข้อความ HA ควรเลือกใช้ Streams มากกว่า Pub/Sub เสมอ

# 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

Redis ใน HA

Redis ขยาย Redis ด้วยโครงสร้างข้อมูลและฟังก์ชันพิเศษ สามรายการที่ได้รับความนิยมสูงสุด ได้แก่ RedisJSON, RediSearch และ RedisTimeSeries ทำงานร่วมกับการจำลองแบบและ Sentinel แต่มีข้อควรพิจารณาเฉพาะในการปรับใช้ 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

เมื่อรัน Redis Stack (ชุดโมดูล) ใน HA ตรวจสอบให้แน่ใจว่าโหนดทั้งหมด — ต้นแบบและเรพลิกา — มีการติดตั้งเวอร์ชันโมดูลที่เหมือนกัน คำสั่งของโมดูลจะถูกจำลองแบบผ่านสตรีมการจำลองแบบมาตรฐาน ดังนั้นแบบจำลองจะต้องสามารถดำเนินการได้ หลังจากเกิดข้อผิดพลาด ดัชนี 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 INFO, Prometheus และ Grafana

เป็นรากฐานของความเป็นเลิศในการปฏิบัติงานสำหรับ Redis HA Redis เปิดเผยตัวชี้วัดภายในที่หลากหลายผ่านคำสั่งINFOซึ่งผู้ส่งออก 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 แบบดั้งเดิมเป็นแบบเธรดเดียวสำหรับการประมวลผลคำสั่ง — Dragonfly ใช้สถาปัตยกรรมที่ไม่มีการแชร์กับหลายเธรดเพื่อให้ได้ปริมาณงานที่สูงขึ้นอย่างมากบนเครื่องแบบมัลติคอร์ รองรับโปรโตคอล 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

Dragonfly: แบบมัลติเธรด (ทรูพุต 25 เท่าบน 8 คอร์ เทียบกับ Redis แบบเธรดเดี่ยว), ประสิทธิภาพหน่วยความจำที่ดีขึ้น (ใช้ตารางแฮช Dash แทน Redis dict), สแน็ปช็อตในตัวโดยไม่มีค่าโสหุ้ย fork() และการสนับสนุนดั้งเดิมสำหรับชุดข้อมูลขนาดใหญ่ อย่างไรก็ตาม ในปี 2026 การรองรับการจำลองแบบของ Dragonfly ยังคงอยู่ในช่วงเติบโต โดยรองรับการจำลองแบบแบบหลักแต่ยังไม่มีระบบเฟลโอเวอร์อัตโนมัติที่เทียบเท่ากับ Sentinel สำหรับ HA ให้ใช้การตรวจสอบสภาพ Kubernetes และนโยบายการรีสตาร์ท StatefulSet หรือปรับใช้หลังโหลดบาลานเซอร์ด้วยการเฟลโอเวอร์ระดับแอปพลิเคชัน

คีย์DB

KeyDB เป็นทางแยกแบบมัลติเธรดของ Redis ที่ดูแลโดย Snap (บริษัทที่อยู่เบื้องหลัง Snapchat) มันเข้ากันได้อย่างสมบูรณ์กับ Redis และเพิ่มมัลติเธรด, การจำลองแบบที่ใช้งานอยู่ (มัลติมาสเตอร์), การจัดระดับพื้นที่เก็บข้อมูล FLASH และการหมดอายุของคีย์ย่อย การจำลองแบบแอคทีฟและแอคทีฟของ 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 แบบเธรดเดียวที่สามารถให้ได้ แต่ต้องการอยู่ใกล้กับฐานโค้ด Redis มากกว่า Dragonfly

การปรับแต่งประสิทธิภาพ

งานวางท่อ

Pipelining รวมชุดคำสั่งหลายคำสั่งไว้ในเครือข่ายเดียวแบบไปกลับ ช่วยลดเวลาแฝงสำหรับการดำเนินการจำนวนมากได้อย่างมาก แทนที่จะรอแต่ละคำตอบก่อนส่งคำสั่งถัดไป ไคลเอนต์จะส่งคำสั่งทั้งหมดในครั้งเดียวและอ่านคำตอบทั้งหมดพร้อมกัน

# 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

การเขียนสคริปต์ Lua

Lua ดำเนินการแบบอะตอมมิกบนเซิร์ฟเวอร์ Redis ซึ่งช่วยลดการเดินทางไปกลับสำหรับการดำเนินการที่ซับซ้อน และรับประกันว่าจะไม่มีคำสั่งอื่นใดดำเนินการระหว่างการทำงานของสคริปต์ ในคลัสเตอร์ Redis ตรวจสอบให้แน่ใจว่าคีย์ทั้งหมดที่เข้าถึงโดยสคริปต์ Lua อยู่ในช่องแฮชเดียวกันโดยใช้แฮชแท็ก

# 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: Master ล้มเหลว Sentinel ส่งเสริมการจำลอง

# 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: Resync Storm เต็มรูปแบบหลังจากพาร์ติชันเครือข่าย

# 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

การวางแผนความจุและกลยุทธ์การปรับขนาด

สำหรับ Redis HA เกี่ยวข้องกับการประมาณความต้องการหน่วยความจำ แบนด์วิดท์เครือข่าย และการใช้งาน 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

การปรับขนาดแนวนอนด้วยคลัสเตอร์ Redis

# 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 Sentinelที่มีอินสแตนซ์ Sentinel สามอินสแตนซ์ที่ตรวจสอบต้นแบบและแบบจำลองสองรายการมอบโซลูชัน HA ที่ผ่านการพิสูจน์แล้วและผ่านการทดสอบการต่อสู้พร้อมระบบเฟลโอเวอร์อัตโนมัติภายในเวลาไม่ถึง 30 วินาที เมื่อคุณต้องการสเกลแนวนอนที่เกินกว่าปริมาณงานหรือความจุหน่วยความจำของต้นแบบตัวเดียวRedis Clusterจะกระจายชุดข้อมูลไปยังชาร์ดหลาย ๆ ชาร์ด ในขณะที่ยังคงรักษาการเฟลโอเวอร์ในตัวต่อชาร์ด สำหรับสภาพแวดล้อม Kubernetes ตัวดำเนินการเช่นSpotahomeและOpsTreeเข้ารหัสแนวทางปฏิบัติที่ดีที่สุดในการปฏิบัติงานเป็น CRD ที่เปิดเผย ในขณะที่Redis Enterpriseมอบตัวเลือกที่มีฟีเจอร์หลากหลายที่สุดพร้อมการจำลองทางภูมิศาสตร์แบบ Active-Active และการสนับสนุนโมดูล

บริการที่จัดการบนคลาวด์ —AWS ElastiCache,Azure Cache สำหรับ Redis, และGCP Memorystore— ขจัดภาระการดำเนินงานของการรันโครงสร้างพื้นฐาน Redis แต่มาพร้อมกับความยืดหยุ่นที่ลดลงและต้นทุนที่สูงขึ้นตามขนาด สำหรับองค์กรที่มีโครงสร้างพื้นฐานแบบ Bare Metalk3s พร้อม Rancher และ Longhornมอบทางเลือกโอเพ่นซอร์สที่ไม่ขึ้นอยู่กับคลาวด์โดยสมบูรณ์ โดยนำเสนอ HA ระดับองค์กรโดยไม่ต้องผูกมัดกับผู้จำหน่าย

ทางเลือกอื่น เช่นDragonflyและKeyDBคุ้มค่าแก่การประเมินสำหรับกรณีการใช้งานเฉพาะ — Dragonfly สำหรับการประมวลผลแบบมัลติเธรดแบบดิบบนเครื่องขนาดใหญ่ และ KeyDB สำหรับการจำลองแบบ multi-master แบบแอคทีฟและแอคทีฟ ทั้งสองเข้ากันได้กับ Redis และสามารถใช้เป็นอุปกรณ์ทดแทนแบบดรอปอินได้ในหลายสถานการณ์

ไม่ว่าคุณจะเลือกสถาปัตยกรรมแบบใด พื้นฐานการปฏิบัติงานจะยังคงที่: กำหนดค่าการคงอยู่ที่เหมาะสม (RDB + AOF แบบไฮบริด), บังคับใช้min-replicas-to-writeเพื่อป้องกันการสูญเสียข้อมูลแบบ split-brain, ปรับขนาด Replication Backlog ของคุณสำหรับปริมาณการเขียนของคุณ, เข้ารหัสการรับส่งข้อมูลทั้งหมดด้วย TLS, บังคับใช้การเข้าถึงที่มีสิทธิพิเศษน้อยที่สุดด้วย ACL, ตรวจสอบความล่าช้าในการจำลองและการใช้หน่วยความจำด้วย Prometheus และ Grafana, สำรองข้อมูลสแน็ปช็อต RDB เพื่อนอกสถานที่ที่มีความคงทน พื้นที่เก็บข้อมูลและ — ที่สำคัญที่สุด — ทดสอบการเฟลโอเวอร์ของคุณเป็นประจำ ระบบเฟลโอเวอร์ที่ไม่เคยทดสอบคือระบบที่ใช้งานไม่ได้ ดำเนินการฝึกซ้อมเฟลโอเวอร์รายเดือน อัดฉีดความล้มเหลวด้วยเครื่องมือทางวิศวกรรมที่วุ่นวาย และวัดเวลาการกู้คืนจริงของคุณ ความมั่นใจที่คุณได้รับจากการทดสอบอย่างเป็นระบบคือสิ่งที่แยกการใช้งาน Redis ที่จะเอาตัวรอดจากเหตุการณ์การผลิตจากเหตุการณ์ที่เปลี่ยนความล้มเหลวของเซิร์ฟเวอร์ไปสู่การหยุดทำงานทั่วทั้งบริษัท