Redis Tehlikeli Komutları

Merhaba,

Geçtiğimiz haftalarda yeni bir tecrübe edindim. Hızlı olan Redis nasıl olurda bir DB den daha yavaş hale gelir, bozulur ?

Bu konuda araştırmalarımı sizinle paylaşmak isterim. Hepsini bir halde iletiyorum. Buradan bakarak Redislerinizi güncelleyebilir veya sıfırdan kurulumda dikkat edersiniz. İyi okumalar.

Güzel gözüksün diye AI dan destek aldım emote lara takılmayın :D

Redis’te Tehlikeli Komutlar: Production’da Kullanmamanız Gereken 10 Komut 🔥

📖 Giriş

Redis hızlı ve güçlü bir veritabanıdır, ancak bazı komutları production ortamında kullanmak felakete yol açabilir.

⚠️ Tehlike Seviyesi Skalası

🟢 Güvenli       - Production'da kullanılabilir
🟡 Dikkatli      - Belirli koşullarda kullanılabilir
🟠 Riskli        - Çok dikkatli kullanılmalı
🔴 Tehlikeli     - Production'da kullanılmamalı
⚫ Felaket       - Sistemi çökertebilir

1. KEYS — Pattern Matching (⚫ FELAKET)

Ne Yapar?

Pattern’e uyan tüm key’leri listeler.

Neden Tehlikeli?

# 5 milyon key var
KEYS "user:*"  # 2-5 saniye bloke!

# Bu süre boyunca:
- Redis tamamen bloke ❌
- Tüm diğer komutlar bekler ❌
- Connection timeout ❌
- Cascade failure ❌

Kompleksite: O(N) — N = toplam key sayısı

Güvenli Alternatif: SCAN

# ❌ YANLIŞ
KEYS "user:*"

# ✅ DOĞRU
SCAN 0 MATCH "user:*" COUNT 100

# Her iterasyon küçük, diğer komutları bloke etmez

Kod Örneği:

# ❌ YANLIŞ
def get_all_users():
    return redis.keys("user:*")  # Bloke eder!

# ✅ DOĞRU
def get_all_users():
    cursor = 0
    users = []
    while True:
        cursor, keys = redis.scan(cursor, match="user:*", count=100)
        users.extend(keys)
        if cursor == 0:
            break
    return users

2. FLUSHDB / FLUSHALL (⚫ FELAKET)

Ne Yapar?

• FLUSHDB: Aktif database'deki tüm key'leri siler
• FLUSHALL: Tüm database'lerdeki tüm key'leri siler

Neden Tehlikeli?

# Tek komutla 10 milyon key silinir
FLUSHALL

# Sonuç:
- Tüm cache kaybolur ❌
- Tüm session'lar yok olur ❌
- Database'e ani yük ❌
- Application çöker ❌
- Veri kaybı (kalıcı!) ❌

Gerçek Senaryo:

15:30:00 → Developer: "Test database'ini temizleyeyim"
15:30:01 → Yanlışlıkla production redis'e bağlanmış
15:30:02 → FLUSHALL
15:30:03 → 15 milyon key silindi
15:30:05 → Application error rate %100
15:30:10 → Database CPU %300 (cache yok, her şey DB'den)
15:30:30 → Total outage
Recovery: 2 saat, $500,000 kayıp

Koruma:

# redis.conf
rename-command FLUSHDB ""
rename-command FLUSHALL ""

# Test
redis-cli FLUSHALL
# (error) ERR unknown command 'FLUSHALL'

Güvenli Alternatif:

# Belirli pattern'deki key'leri sil
def safe_flush_pattern(pattern):
    cursor = 0
    while True:
        cursor, keys = redis.scan(cursor, match=pattern, count=100)
        if keys:
            redis.delete(*keys)
        if cursor == 0:
            break

# Kullanım
safe_flush_pattern("temp:*")  # Sadece temp key'ler

3. SMEMBERS / HGETALL / LRANGE (🔴 TEHLİKELİ)

Ne Yapar?

Set, Hash veya List’in tüm elemanlarını döndürür.

Neden Tehlikeli?

# Set'te 1 milyon eleman var
SMEMBERS blacklist:all  # 500ms+ bloke!

# Hash'te 100,000 field var
HGETALL user:1001  # 200ms+ bloke!

# List'te 500,000 eleman var
LRANGE queue:pending 0 -1  # 300ms+ bloke!

Problem:

Eleman sayısı   | Response Time | Memory
---------------|---------------|--------
100            | 1ms           | 10KB
1,000          | 5ms           | 100KB
10,000         | 50ms          | 1MB
100,000        | 500ms         | 10MB  ❌
1,000,000      | 5000ms        | 100MB ❌

Güvenli Alternatif: SSCAN / HSCAN / Pagination

# ❌ YANLIŞ - Tüm elemanları al
SMEMBERS blacklist:all

# ✅ DOĞRU - Parça parça al
SSCAN blacklist:all 0 COUNT 100

# ❌ YANLIŞ - Tüm hash al
HGETALL user:1001

# ✅ DOĞRU - Parça parça al
HSCAN user:1001 0 COUNT 100

# ❌ YANLIŞ - Tüm list al
LRANGE queue:pending 0 -1

# ✅ DOĞRU - Pagination
LRANGE queue:pending 0 99    # İlk 100
LRANGE queue:pending 100 199 # Sonraki 100

Kod Örneği:

# ❌ YANLIŞ
def get_all_blacklist():
    return redis.smembers("blacklist:all")  # 1 milyon eleman!

# ✅ DOĞRU
def get_blacklist_paginated(page=0, size=100):
    start = page * size
    return redis.sscan("blacklist:all", start, count=size)

# ✅ DAHA İYİ - Iterator
def iter_blacklist(batch_size=100):
    cursor = 0
    while True:
        cursor, items = redis.sscan("blacklist:all", cursor, count=batch_size)
        for item in items:
            yield item
        if cursor == 0:
            break

# Kullanım
for phone in iter_blacklist():
    process(phone)

4. SUNIONSTORE / SINTERSTORE / SDIFFSTORE (🔴 TEHLİKELİ)

Ne Yapar?

Birden fazla set’i birleştirir, kesiştir veya farkını alır ve sonucu yeni bir key’e yazar.

Neden Tehlikeli?

# Her set'te 500,000 eleman var
SUNIONSTORE result set1 set2 set3 set4 set5

# Bu komut:
1. 5 set'i memory'ye yükler (2.5 milyon eleman)
2. Union işlemi yapar (CPU yoğun)
3. Sonucu yeni key'e yazar (1.2 milyon unique)
4. Süre: 2-5 saniye (BLOKE!)

Gerçek Senaryo:

# Her SMS gönderiminde:
def check_blacklist(customer_id, phones):
    # 10 farklı blacklist var
    blacklist_keys = [
        f"blacklist:customer:{customer_id}",
        f"blacklist:global",
        f"blacklist:temp:{today}",
        # ... 7 tane daha
    ]

    # ❌ Her seferinde SUNIONSTORE
    result_key = f"blacklist:result:{uuid.uuid4()}"
    redis.sunionstore(result_key, *blacklist_keys)

    # Kontrol
    for phone in phones:
        if redis.sismember(result_key, phone):
            return False

    return True

# SORUN:
# - Saniyede 100 SMS
# - Her SMS için SUNIONSTORE (2 saniye)
# - Redis sürekli bloke!

Güvenli Alternatif: Cache + Incremental Check

# ✅ DOĞRU - Cache kullan
@lru_cache(maxsize=1000)
def get_merged_blacklist(customer_id):
    """5 dakika cache'le"""
    blacklist_keys = get_blacklist_keys(customer_id)

    # İlk seferde birleştir
    merged = set()
    for key in blacklist_keys:
        merged.update(redis.smembers(key))

    return merged

# Kullanım
blacklist = get_merged_blacklist(customer_id)
if phone in blacklist:
    return False

# ✅ DAHA İYİ - Incremental check
def is_blacklisted(customer_id, phone):
    blacklist_keys = get_blacklist_keys(customer_id)

    # Her key'i teker teker kontrol et (hızlı!)
    for key in blacklist_keys:
        if redis.sismember(key, phone):  # O(1) - Hızlı!
            return True

    return False

Benchmark:

Method              | Latency  | Memory  | Redis Blocking
--------------------|----------|---------|---------------
SUNIONSTORE         | 2500ms   | 100MB   | ✅ Yes
Cache (5min)        | 5ms      | 50MB    | ❌ No
Incremental Check   | 15ms     | 1MB     | ❌ No (minimal)

5. SAVE (🔴 TEHLİKELİ)

Ne Yapar?

Redis’i bloke ederek synchronous RDB snapshot alır.

Neden Tehlikeli?

# 10GB data var
SAVE

# Ne olur:
1. Redis tamamen BLOKE olur
2. Disk'e snapshot yazılır (10-30 saniye)
3. Bu süre boyunca HİÇBİR KOMUT çalışmaz
4. Total outage!

Senaryo:

14:00:00 → Cron job: redis-cli SAVE
14:00:01 → Redis frozen (10GB dump başladı)
14:00:15 → 15 saniye hiçbir response yok
14:00:15 → 5,000+ request timeout
14:00:15 → Application crash
14:00:30 → SAVE tamamlandı ama çok geç
Recovery: 5 dakika

Güvenli Alternatif: BGSAVE

# ❌ YANLIŞ
SAVE  # Bloke eder!

# ✅ DOĞRU
BGSAVE  # Background'da çalışır, bloke etmez

# Kontrol
redis-cli LASTSAVE  # Son snapshot zamanı

Config:

# redis.conf
# Otomatik snapshot (production önerilen)
save 900 1       # 15 dakikada 1 değişiklik
save 300 10      # 5 dakikada 10 değişiklik
save 60 10000    # 1 dakikada 10000 değişiklik

# SAVE komutunu kapat
rename-command SAVE ""

6. SORT (🔴 TEHLİKELİ)

Ne Yapar?

List, Set veya Sorted Set’i sıralar.

Neden Tehlikeli?

# 1 milyon elemanlı list
SORT mylist LIMIT 0 100  # 500ms+ bloke!

# Dış key'lerle join
SORT mylist BY weight:* GET object:*  # 2000ms+ bloke!

Kompleksite: O(N+M*log(M))

• N = list boyutu
• M = döndürülen eleman sayısı

Problem:

# ❌ YANLIŞ - Her request'te SORT
def get_leaderboard(page=1, size=10):
    # 1 milyon user var
    start = (page - 1) * size

    # Her seferinde tüm listeyi sıralar!
    return redis.sort(
        "users:all",
        by="user:*->score",
        get="user:*->name",
        start=start,
        num=size,
        desc=True
    )
# Her call: 1-2 saniye bloke!

Güvenli Alternatif: Sorted Set

# ✅ DOĞRU - Sorted Set kullan (zaten sıralı!)
def get_leaderboard(page=1, size=10):
    start = (page - 1) * size
    end = start + size - 1

    # O(log(N)+M) - Çok hızlı!
    return redis.zrevrange(
        "leaderboard",
        start,
        end,
        withscores=True
    )

# Score update
redis.zadd("leaderboard", {user_id: score})

Benchmark:

Method              | 1M elements | Latency
--------------------|-------------|--------
SORT                | O(N*log(N)) | 1500ms
Sorted Set (ZRANGE) | O(log(N)+M) | 2ms

7. MIGRATE (🟠 RİSKLİ)

Ne Yapar?

Key’i atomically başka bir Redis instance’a taşır.

Neden Riskli?

# Büyük key migration
MIGRATE target_host 6379 bigkey 0 5000

# Problem:
1. Source Redis bloke olur
2. Target Redis bloke olur
3. Network transfer time
4. Büyük key'ler için çok uzun sürer

Güvenli Kullanım:

# ✅ COPY option kullan
MIGRATE target_host 6379 key 0 5000 COPY

# ✅ Küçük key'ler için
MIGRATE target_host 6379 small_key 0 1000

# ❌ Büyük key'ler için kullanma
# Önce key'i parçala, sonra migrate et

8. DEBUG ve ADMIN Komutları (🔴 TEHLİKELİ)

Tehlikeli DEBUG Komutları:

# ⚫ FELAKET - Redis'i çökertir
DEBUG SEGFAULT  # Intentional crash!

# 🔴 TEHLİKELİ - Redis'i bloke eder
DEBUG SLEEP 10  # 10 saniye uyut

# 🔴 TEHLİKELİ - Memory dump
DEBUG OBJECT key  # Büyük key'ler için yavaş

# 🔴 TEHLİKELİ - Full reload
DEBUG RELOAD  # Redis restart gibi

Koruma:

# redis.conf
rename-command DEBUG ""
rename-command SHUTDOWN ""
rename-command CONFIG "SECRET_CONFIG_COMMAND"

9. MONITOR (🔴 TEHLİKELİ)

Ne Yapar?

Tüm Redis komutlarını gerçek zamanlı izler.

Neden Tehlikeli?

# MONITOR başlat
redis-cli MONITOR

# Ne olur:
1. Her komut client'a gönderilir
2. Yüksek trafikte (10k ops/sec):
   - Network bandwidth dolar
   - Redis CPU artar
   - Latency artar

Problem:

MONITOR aktifken:
Normal latency: 1ms → 15ms
CPU usage: 20% → 80%
Network: 10MB/s → 500MB/s

Production'da DİSABLE!

Güvenli Alternatif:

# ✅ Slowlog kullan
redis-cli SLOWLOG GET 10

# ✅ INFO stats
redis-cli INFO stats

# ✅ Sampling
redis-cli --latency-history

# ✅ Redis Insights (GUI)

10. EVAL (Long Running Scripts) (🟠 RİSKLİ)

Ne Yapar?

Lua script çalıştırır.

Neden Riskli?

-- ❌ YANLIŞ - Sonsuz döngü
EVAL "while true do end" 0

-- ❌ YANLIŞ - Yavaş script
EVAL "
    local keys = redis.call('KEYS', 'user:*')
    for i=1,#keys do
        redis.call('GET', keys[i])
    end
    return #keys
" 0

Problem:

Script çalışırken:
- Redis bloke olur
- Script timeout olana kadar bekler
- KILL ile durdurulmaya çalışılır ama...
- Eğer yazma işlemi yaptıysa KILL çalışmaz!

Güvenli Kullanım:

-- ✅ DOĞRU - Hızlı, atomic işlem
EVAL "
    local current = redis.call('GET', KEYS[1])
    if not current then
        redis.call('SET', KEYS[1], ARGV[1])
        return 1
    end
    return 0
" 1 mykey myvalue

-- ✅ DOĞRU - SCAN kullan
EVAL "
    local cursor = '0'
    local count = 0
    repeat
        local result = redis.call('SCAN', cursor, 'MATCH', ARGV[1], 'COUNT', 100)
        cursor = result[1]
        count = count + #result[2]
    until cursor == '0'
    return count
" 0 "user:*"

Best Practices:

-- ✅ Timeout set et
redis.call('CONFIG', 'SET', 'lua-time-limit', '5000')  # 5 saniye

-- ✅ Küçük batch'ler
-- ✅ KEYS kullanma, SCAN kullan
-- ✅ Test et (development'ta)

📊 Tehlike Karşılaştırma Tablosu

Komut Tehlike Bloke Eder? Alternatif Production’da Kullanım KEYS ⚫ Felaket ✅ Evet SCAN ❌ Asla FLUSHDB/ALL ⚫ Felaket ✅ Evet Pattern delete ❌ Asla SMEMBERS 🔴 Tehlikeli ✅ Evet (büyük set) SSCAN ⚠️ Küçük set’ler için OK HGETALL 🔴 Tehlikeli ✅ Evet (büyük hash) HSCAN ⚠️ Küçük hash’ler için OK SUNIONSTORE 🔴 Tehlikeli ✅ Evet Cache + Incremental ⚠️ Küçük set’ler için OK SAVE 🔴 Tehlikeli ✅ Evet BGSAVE ❌ Asla SORT 🔴 Tehlikeli ✅ Evet Sorted Set ⚠️ Küçük listeler için OK MIGRATE 🟠 Riskli ✅ Evet COPY option ⚠️ Dikkatli kullan DEBUG 🔴 Tehlikeli ✅ Evet INFO, SLOWLOG ❌ Disable et MONITOR 🔴 Tehlikeli Partial Slowlog ❌ Production’da kullanma EVAL 🟠 Riskli ✅ Evet (script’e bağlı) Küçük script’ler ⚠️ Test et LRANGE 0 -1 🔴 Tehlikeli ✅ Evet (büyük list) Pagination ⚠️ Küçük listeler için OK

🛡️ Kapsamlı Koruma Stratejisi

1. Redis Config Hardening

# redis.conf

# Tehlikeli komutları kapat
rename-command KEYS ""
rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command SAVE ""
rename-command DEBUG ""
rename-command SHUTDOWN ""
rename-command CONFIG "SUPER_SECRET_CONFIG_xyz123"

# Timeout'lar
timeout 300
tcp-keepalive 60

# Memory
maxmemory 10gb
maxmemory-policy allkeys-lru

# Persistence (SAVE yerine)
save 900 1
save 300 10
save 60 10000

# Slowlog
slowlog-log-slower-than 10000  # 10ms
slowlog-max-len 128

# Lua timeout
lua-time-limit 5000  # 5 saniye

2. Application-Level Protection

class SafeRedis:
    """Production-safe Redis wrapper"""

    BLOCKED_COMMANDS = {
        'KEYS', 'FLUSHDB', 'FLUSHALL', 'SAVE',
        'DEBUG', 'SHUTDOWN', 'MONITOR'
    }

    RISKY_COMMANDS = {
        'SMEMBERS', 'HGETALL', 'LRANGE',
        'SUNIONSTORE', 'SORT'
    }

    MAX_BATCH_SIZE = 1000

    def __init__(self, redis_client):
        self.client = redis_client
        self.logger = logging.getLogger(__name__)

    def execute_command(self, *args):
        command = args[0].upper()

        # Blocked komutları reddet
        if command in self.BLOCKED_COMMANDS:
            raise ValueError(
                f"Command '{command}' is blocked. "
                f"Use safe alternative."
            )

        # Risky komutları logla
        if command in self.RISKY_COMMANDS:
            self.logger.warning(
                f"Risky command '{command}' used. "
                f"Consider using alternative."
            )

        return self.client.execute_command(*args)

    # Safe wrappers
    def safe_keys(self, pattern, max_keys=None):
        """SCAN kullanarak key'leri al"""
        cursor = 0
        keys = []

        while True:
            cursor, batch = self.client.scan(
                cursor,
                match=pattern,
                count=100
            )
            keys.extend(batch)

            if max_keys and len(keys) >= max_keys:
                return keys[:max_keys]

            if cursor == 0:
                break

        return keys

    def safe_smembers(self, key, max_members=None):
        """SSCAN kullanarak set elemanlarını al"""
        # Önce boyutu kontrol et
        size = self.client.scard(key)

        if size > self.MAX_BATCH_SIZE:
            self.logger.warning(
                f"Large set '{key}' ({size} members). "
                f"Use pagination."
            )

        cursor = 0
        members = []

        while True:
            cursor, batch = self.client.sscan(
                key,
                cursor,
                count=100
            )
            members.extend(batch)

            if max_members and len(members) >= max_members:
                return members[:max_members]

            if cursor == 0:
                break

        return members

    def safe_hgetall(self, key):
        """HSCAN kullanarak hash'i al"""
        size = self.client.hlen(key)

        if size > self.MAX_BATCH_SIZE:
            raise ValueError(
                f"Hash '{key}' too large ({size} fields). "
                f"Use HSCAN or get specific fields."
            )

        return self.client.hgetall(key)

# Kullanım
redis = SafeRedis(redis.Redis())

# ✅ Güvenli
keys = redis.safe_keys("user:*", max_keys=1000)

# ❌ Hata fırlatır
redis.execute_command("KEYS", "*")

3. Monitoring & Alerting

# Prometheus alerts
groups:
  - name: redis_dangerous_commands
    rules:
      # Slow command alert
      - alert: RedisSlowCommand
        expr: redis_command_duration_seconds > 0.1
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Redis slow command detected"
          description: "Command took {{ $value }}s"

      # Blocked command attempt
      - alert: RedisBlockedCommand
        expr: rate(redis_blocked_commands_total[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "Blocked Redis command attempted"

      # High latency
      - alert: RedisHighLatency
        expr: redis_latency_ms > 100
        for: 5m
        labels:
          severity: warning

      # Memory usage
      - alert: RedisMemoryHigh
        expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.9
        labels:
          severity: warning

4. Pre-Deploy Checklist

#!/bin/bash
# redis_pre_deploy_check.sh

echo "=== Redis Security Check ==="

# 1. Config kontrolü
echo "Checking redis.conf..."
if grep -q "^rename-command KEYS" /etc/redis/redis.conf; then
    echo "✅ KEYS disabled"
else
    echo "❌ KEYS not disabled!"
    exit 1
fi

# 2. Code scan
echo "Scanning code for dangerous commands..."
DANGEROUS=(
    "\\\\.keys\\\\("
    "\\\\.flushdb\\\\("
    "\\\\.flushall\\\\("
    "\\\\.save\\\\("
    "redis\\\\.call.*KEYS"
)

for pattern in "${DANGEROUS[@]}"; do
    if grep -r "$pattern" ./src/; then
        echo "❌ Found dangerous pattern: $pattern"
        exit 1
    fi
done

echo "✅ No dangerous commands found"

# 3. Load test
echo "Running load test..."
redis-benchmark -t get,set -n 100000 -c 50 -q

echo "=== All checks passed ✅ ==="

🎓 Best Practices Özeti

✅ YAPMANIZ GEREKENLER

1. SCAN kullanın (KEYS yerine)
2. SSCAN/HSCAN kullanın (SMEMBERS/HGETALL yerine)
3. BGSAVE kullanın (SAVE yerine)
4. Sorted Set kullanın (SORT yerine)
5. Pagination kullanın
6. Timeout'lar ayarlayın
7. Monitoring kurun
8. Load test yapın
9. Tehlikeli komutları disable edin
10. Code review yapın

❌ YAPMAMANIZ GEREKENLER

1. KEYS kullanmayın
2. FLUSHDB/FLUSHALL kullanmayın
3. SAVE kullanmayın
4. Büyük collection'ları tamamen almayın
5. SUNIONSTORE'u sık kullanmayın
6. Production'da MONITOR çalıştırmayın
7. Uzun Lua script'leri çalıştırmayın
8. DEBUG komutları kullanmayın
9. Test etmeden deploy etmeyin
10. Monitoring olmadan production'a geçmeyin

📚 Migration Planı

Mevcut kodunuzda tehlikeli komutlar varsa:

Adım 1: Audit

# Code audit script
#!/bin/bash

echo "=== Redis Dangerous Commands Audit ==="

# Tehlikeli komutları ara
grep -rn "\\\\.keys\\\\(" ./src/ > audit_keys.txt
grep -rn "\\\\.smembers\\\\(" ./src/ > audit_smembers.txt
grep -rn "\\\\.hgetall\\\\(" ./src/ > audit_hgetall.txt
grep -rn "\\\\.sunionstore\\\\(" ./src/ > audit_sunionstore.txt

echo "Audit complete. Check audit_*.txt files"

Adım 2: Priority

P0 (Critical): Sık çalışan, production-critical
P1 (High): Scheduled job'lar
P2 (Medium): Admin işlemleri
P3 (Low): Development script'leri

Adım 3: Refactor

Her tehlikeli komut için yukarıdaki alternatifleri uygulayın.

Adım 4: Test

# Unit test
def test_no_dangerous_commands():
    # Mock Redis
    mock_redis = Mock(spec=redis.Redis)

    # Dangerous komutları blokla
    mock_redis.keys.side_effect = Exception("KEYS is blocked!")

    # Application kodu çalışabilmeli
    result = my_function(mock_redis)

    # SCAN kullanıldığını doğrula
    mock_redis.scan.assert_called()
    assert mock_redis.keys.call_count == 0

Adım 5: Deploy

# Canary deploy
kubectl set image deployment/app app=app:v2 --record
kubectl rollout status deployment/app

# Monitor
watch -n 1 'redis-cli INFO stats | grep instantaneous_ops_per_sec'

🎯 Sonuç

Redis güçlü bir araçtır, ancak bazı komutları production ortamında felakete yol açabilir:

Komut Kategorisi Etki Önlem Pattern Matching (KEYS) ⚫ Felaket SCAN kullan, disable et Mass Delete (FLUSH*) ⚫ Felaket Disable et, pattern delete kullan Full Collection (SMEMBERS, HGETALL) 🔴 Tehlikeli SCAN varyantları, pagination Set Operations (SUNIONSTORE) 🔴 Tehlikeli Cache, incremental check Persistence (SAVE) 🔴 Tehlikeli BGSAVE, otomatik snapshot Sorting (SORT) 🔴 Tehlikeli Sorted Set kullan Debug/Admin 🔴 Tehlikeli Disable et, alternatifler kullan

Hatırlayın:

“Production ortamında Redis’i kullanmak otomobil kullanmak gibidir. Güvenli kullanırsanız sizi hedefinize hızla ulaştırır. Ama yanlış komutları kullanırsanız… 💥”