Redis Kurulumu ve Önbellekleme: Uygulama Performansını Artırın

Redis Kurulumu, Önbellekleme ve Performans Rehberi (2026)

Sayfa açılışı 3 saniye, MySQL CPU %95'te — ama bakıyorsunuz veriler aslında her 5 dakikada bir değişiyor. Neden her sayfa yüklemesinde aynı sorguları çalıştırıyoruz? İşte Redis'in çözdüğü sorun tam olarak bu.

Redis (Remote Dictionary Server), verileri disk yerine bellekte tutan açık kaynaklı bir anahtar-değer deposudur. Doğru yapılandırıldığında veritabanı yükünü %70-90 oranında düşürebilir; oturum paylaşımından gerçek zamanlı mesajlaşmaya kadar onlarca farklı senaryoda görev yapabilir. Ama her şey gibi Redis de her durumda doğru araç değil. Günde 1000 ziyaretin altındaki bir site için Redis kurulum karmaşıklığı fazla; LiteSpeed LSCache zaten %95 yükü kapatıyor. Redis ihtiyacı şu durumlarda ortaya çıkıyor: yüksek dinamik veritabanı sorgusu (e-ticaret, forum, üyelik sistemi), birden fazla uygulama sunucusu arasında oturum paylaşımı ya da WebSocket kullanan Pub/Sub gerektiren uygulamalar.

Büyükweb perspektifi: cPanel hosting paketlerimizde Redis otomatik aktif değildir; PHP Redis eklentisi ve Redis sunucusu, kullanıcı izolasyonu ile birlikte destek hattımız üzerinden talep bazlı aktive edilir (0850 302 60 70). VDS paketlerinde ise Redis tamamen self-host kurulabilir — aşağıdaki apt veya dnf komutlarıyla dakikalar içinde çalışır hale gelir.

Redis Neyi Çözer — Kullanım Senaryoları

Senaryo	Redis rolü	Alternatif
Veritabanı sorgu cache	Sık çalışan SELECT sonuçlarını bellekte tut	Uygulama düzeyi PHP cache
Session yönetimi	Çok sunuculu dağıtık oturum paylaşımı	Dosya/DB tabanlı session
Rate limiting	API istek sayacı (INCR + EXPIRE)	Veritabanı sayacı (yavaş)
Sıralama tablosu	Sorted Set ile anlık leaderboard	JOIN'li sorgu (yavaş)
İş kuyruğu (Queue)	List veri yapısıyla RPUSH/LPOP	Cron + DB polling
Pub/Sub mesajlaşma	WebSocket arka plan kanal yönetimi	Polling
WordPress Object Cache	DB sorgularını uygulama katmanında önbelleğe al	Transient API (DB tabanlı)

Küçük site veya blog için bu tablonun büyük kısmı overkill. Redis kurulumu ancak üstteki senaryolardan en az biri gerçekten varsa anlamlı.

VDS'de Redis Kurulumu

Ubuntu 22.04 / Debian 12

apt update
apt install redis-server -y
systemctl enable --now redis-server
redis-cli ping
# PONG — Redis çalışıyor

Redis 7.x (LTS), Ubuntu 22.04 depolarında hazır gelir. Daha güncel sürüm için:

# Redis resmi paket deposu
curl -fsSL https://packages.redis.io/gpg | gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/redis.list
apt update && apt install redis -y
redis-server --version
# Redis server v=7.x.x

AlmaLinux 9 / Rocky Linux 9

dnf install redis -y
systemctl enable --now redis
redis-cli ping
# PONG

Daha güncel versiyon için:

dnf module enable redis:7 -y
dnf install redis -y

Kurulum Doğrulama

# Servis durumu
systemctl status redis

# Bağlantı testi
redis-cli -h 127.0.0.1 -p 6379 ping

# Versiyon bilgisi
redis-cli INFO server | grep redis_version

redis.conf Kritik Ayarlar

Redis'in iki yapılandırma dosyası yolu:

• Ubuntu/Debian: /etc/redis/redis.conf
• AlmaLinux/RHEL: /etc/redis.conf

Temel Güvenlik ve Bellek Ayarları

# Sadece yerel bağlantı kabul et (dış dünyaya açma)
bind 127.0.0.1 -::1

# Şifre koru
requirepass guclu_bir_sifre_buraya

# Maksimum bellek limiti (VDS RAM'inin %25-33'ü ideal)
maxmemory 512mb

# Bellek dolunca ne yapılsın?
# allkeys-lru: tüm anahtarlardan en az kullanılanı sil (cache için ideal)
# volatile-lru: sadece TTL olan anahtarlardan sil (karışık kullanım için)
# noeviction: hata döndür, silme (session gibi kritik veri için)
maxmemory-policy allkeys-lru

# Lazy freeing: büyük veri silme işlemi arka planda (ana thread kilitlemez)
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes

# Tehlikeli komutları yeniden adlandırarak devre dışı bırak
rename-command FLUSHALL ""
rename-command DEBUG ""
rename-command CONFIG "gizli_config_komutu"

rename-command ile bir komutu boş string'e ("") çevirmek onu tamamen kapatır; CONFIG gibi kapatılamayacak ama gizlenmesi gereken komutlar ise tahmin edilemez bir isme (örn. gizli_config_komutu) yeniden adlandırılır. Böylece şifreyi ele geçiren biri bile veritabanını FLUSHALL ile tek komutta silemez.

Eviction Policy Seçim Rehberi

Policy	Ne zaman?
allkeys-lru	Saf cache — tüm anahtarlar eşit değerde, en eskisi gitsin
volatile-lru	Karışık: TTL olan cache, TTL olmayan kalıcı veri
allkeys-lfu	Redis 4+, LRU yerine kullanım sıklığına göre (daha doğru ama CPU'ya biraz daha yük)
volatile-ttl	En kısa ömürlüyü önce sil
noeviction	Session/queue/kalıcı veri — silme, hata döndür

Persistence: RDB vs AOF

Redis in-memory çalışır ama veriyi diske yazabilir. İki yöntemi var:

RDB (Snapshot — Anlık Görüntü)

# 900 saniyede 1 değişiklik olduysa kaydet
save 900 1
save 300 10
save 60 10000

# RDB dosya adı
dbfilename dump.rdb
dir /var/lib/redis

RDB belirli aralıklarla anlık görüntü alır. Sunucu restart sonrasında son snapshot'tan geri yükler; aralarındaki veri kaybolur.

AOF (Append-Only File)

appendonly yes
appendfilename "appendonly.aof"

# fsync politikası:
# everysec: saniyede bir yaz (önerilen — performans ve güvenlik dengesi)
# always: her komutta yaz (en güvenli, en yavaş)
# no: OS'e bırak (en hızlı, en az güvenli)
appendfsync everysec

# AOF dosyası belirli büyüklüğe gelince compact et
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF her yazma komutunu kayıt altına alır; restart sonrası komutlar tekrar oynatılır. RDB'ye göre daha fazla disk I/O ama veri kaybı riski neredeyse sıfır.

RDB vs AOF Kıyası

Özellik	RDB	AOF
Veri kaybı riski	Snapshot aralığı kadar	Maks 1 sn (everysec)
Restart hızı	Hızlı (binary yükleme)	Yavaş (komutları tekrar oynat)
Disk kullanımı	Az	Fazla (zamanla büyür)
İnsan okunabilirlik	Hayır (binary)	Evet (text log)
Kullanım	Cache-only, veri kaybı önemli değil	Session, queue, kritik veri

Cache kullanımında (veri kaybı önemsiz) RDB yeterli; session veya queue için AOF everysec önerilir. İkisi birlikte açılabilir — Redis önce AOF'tan yükler.

Backup Stratejisi

Persistence dosyaları tek başına yedek değildir — aynı diskte kaldıkları sürece disk arızası veya yanlışlıkla silme durumunda işe yaramaz. RDB snapshot'ını düzenli olarak sunucu dışına kopyalamak gerekir:

# RDB snapshot'ını kopyala (canlı yedek, servis durdurulmadan alınabilir)
cp /var/lib/redis/dump.rdb /backup/redis-$(date +%Y%m%d).rdb

# AOF dosyasını küçültmek için rewrite tetikle (yedekten önce önerilir)
redis-cli BGREWRITEAOF

# Restore: servis durdurulur, dosya yerine konur, sahiplik düzeltilir, başlatılır
systemctl stop redis
cp /backup/redis-20260701.rdb /var/lib/redis/dump.rdb
chown redis:redis /var/lib/redis/dump.rdb
systemctl start redis

Bu kopyalama işini cron ile günlük çalıştırmak ve yedeği ayrı bir diske/sunucuya taşımak önerilir. Büyükweb VDS paketlerinde altyapı seviyesinde günlük otomatik yedekleme mevcuttur; uygulama içi RDB/AOF dosyalarının restore sırasını yukarıdaki gibi bilmek, geri dönüş süresini kısaltır.

Redis Benchmark

Kurulum sonrası performansı yerleşik redis-benchmark aracıyla ölçebilirsiniz:

# 100.000 istek, 50 paralel bağlantı, pipeline 16
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -P 16 -q

# Sadece SET ve GET
redis-benchmark -t set,get -n 100000 -q

VDS ortamında tipik sonuç: SET 180.000+ ops/sn, GET 200.000+ ops/sn. NVMe SSD ve yerel ağ ile bu değerler çoğu uygulama için fazlasıyla yeterli.

PHP Entegrasyonu — phpredis ve Predis

İki seçenek var: phpredis (C extension, hızlı) ve Predis (pure-PHP, bağımlılık yok).

phpredis Kurulumu

# Ubuntu/Debian
apt install php-redis -y
systemctl restart php8.x-fpm   # veya apache2

# AlmaLinux
dnf install php-pecl-redis -y

phpredis ile Cache Örneği

<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->auth('sifreniz');

// Veritabanı sorgu önbellekleme
function getUrunler(PDO $pdo, Redis $redis): array {
    $cacheKey = 'urunler:liste';
    $cached   = $redis->get($cacheKey);

    if ($cached !== false) {
        return json_decode($cached, true);
    }

    $stmt = $pdo->query('SELECT * FROM urunler WHERE aktif = 1 ORDER BY sira');
    $data = $stmt->fetchAll(PDO::FETCH_ASSOC);

    // 5 dakika önbellekle (TTL = 300 sn)
    $redis->setex($cacheKey, 300, json_encode($data));
    return $data;
}

// Session örneği
$redis->setex('session:' . session_id(), 3600, json_encode($_SESSION));

Node.js Entegrasyonu — ioredis

const Redis = require('ioredis');

const redis = new Redis({
  host: '127.0.0.1',
  port: 6379,
  password: 'sifreniz',
  retryStrategy: (times) => Math.min(times * 50, 2000),
});

// Cache-aside pattern
async function getUrun(id) {
  const key    = `urun:${id}`;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const urun = await db.query('SELECT * FROM urunler WHERE id = ?', [id]);
  await redis.setex(key, 300, JSON.stringify(urun));
  return urun;
}

// Rate limiting
async function checkRateLimit(ip) {
  const key   = `rl:${ip}`;
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, 60);
  return count > 100; // dakikada 100 istek
}

WordPress Object Cache Entegrasyonu

WordPress her sayfa yüklemesinde onlarca veritabanı sorgusu atar: kullanıcı bilgisi, menüler, widget'lar, seçenekler. Redis Object Cache bu sorguların sonuçlarını bellekte tutar; ikinci istekte DB'ye gitmez.

cPanel Hosting'de Redis Object Cache

cPanel paketlerimizde Redis aktivasyonu destek hattından talep edilir. Aktif edildikten sonra:

1. WordPress eklenti yöneticisinden Redis Object Cache eklentisini kur
2. wp-config.php dosyasına ekle:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'redis_sifreniz');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_CACHE', true);

3. Eklenti panelinde Enable Object Cache tıkla — durum "Connected" olmalı.

Object Cache Pro vs Redis Object Cache

Eklenti	Fiyat	Avantaj
Redis Object Cache	Ücretsiz	Yeterli, %90 kullanım için ideal
Object Cache Pro	Ücretli ($95+/yıl)	WooCommerce için optimize, daha az bağlantı overhead

Küçük ve orta WordPress siteler için ücretsiz Redis Object Cache yeterli. Yüksek trafikli WooCommerce için Object Cache Pro değerlendirilebilir.

LSCache + Redis Kombinasyonu

LiteSpeed LSCache sayfa cache (tam HTML önbellekleme) yapar; Redis object cache (DB sorgu önbellekleme). İkisi çakışmaz, tamamlayıcıdır:

• LSCache: Giriş yapmamış ziyaretçiler için HTML'i önbellekler → TTFB 50ms altına düşer
• Redis: Giriş yapmış kullanıcılar veya dinamik içerik için DB yükünü düşürür

Bu kombinasyon cPanel hosting'deki maksimum performans senaryosudur.

Redis vs Memcached

Özellik	Redis 7.x	Memcached
Veri yapıları	String, Hash, List, Set, Sorted Set, Stream, Bitmap, HyperLogLog	Yalnızca String
Persistence	RDB + AOF	Hayır (memory-only)
Pub/Sub	Var	Yok
Cluster	Redis Cluster (native)	Uygulama tarafı sharding
ACL (erişim kontrolü)	Redis 6+ ACL	Yok
Çok iş parçacığı	Tek thread (I/O çok iş parçacıklı 6+)	Çok iş parçacıklı
WordPress cache	Object Cache eklentileri var	Hayır (WP eklenti yok)
Tercih	Genel amaç, WordPress, session, queue	Yalnızca basit string cache

Memcached hâlâ geçerli; sadece düz string cache ve çok yüksek paralel bağlantı gerektiğinde tercih edilebilir. Ama Redis neredeyse her zaman daha iyi seçim çünkü ek veri yapıları ve persistence ücretsiz geliyor.

Redis Production Desenleri

Temel cache kullanımının ötesinde, üretim ortamlarında sık karşılaşılan dört desen var: kalıcı mesaj kuyruğu, dağıtık kilit, sıralama tablosu ve atomik rate limiting.

Streams — Kalıcı Mesaj Kuyruğu

Pub/Sub'ın aksine Streams mesajları kalıcı tutar; consumer group ile paylaşımlı tüketim ve replay desteği sağlar — davranış olarak Kafka'ya benzer:

# Mesaj ekle
XADD events * type "order" id 1234

# Tüketici grubu oluştur
XGROUP CREATE events workers $ MKSTREAM

# Gruptan oku (bloklu, en fazla 10 mesaj)
XREADGROUP GROUP workers worker1 COUNT 10 BLOCK 0 STREAMS events >

# İşlendi olarak işaretle
XACK events workers <message-id>

Sipariş işleme, log toplama, event-driven mimari gibi senaryolarda List tabanlı queue'ya (yukarıdaki tabloda geçen RPUSH/LPOP) göre çok daha güvenilirdir; mesaj kaybolmaz, aynı grup içindeki worker'lar arasında yük otomatik dağıtılır.

Distributed Lock (Redlock)

Birden fazla sunucu aynı kaynağa (örn. bir siparişi işleme, bir cron görevini tek instance'ta çalıştırma) aynı anda erişmesin diye dağıtık kilit gerekir:

# SETNX + TTL — basit kilit (tek Redis instance için yeterli)
SET mylock "owner-id" NX PX 30000

# İş bitince kilidi kaldır (owner kontrollü silme Lua ile daha güvenli)
DEL mylock

Tek instance'ta bu yeterlidir; ancak garanti birden fazla bağımsız Redis düğümü üzerinden isteniyorsa Redlock algoritması kullanılır — kilit, 5 bağımsız master'ın çoğunluğunda (quorum) aynı anda alınabildiğinde geçerli sayılır.

Leaderboard (Sıralama Tablosu)

Sorted Set veri yapısı skor bazlı sıralamayı O(log N) karmaşıklıkla çözer — JOIN'li SQL sorgusuna göre çok daha hızlı:

ZADD oyun_skor 9500 "ahmet"
ZADD oyun_skor 8700 "mehmet"

ZREVRANGE oyun_skor 0 9 WITHSCORES   # En yüksek skorlu 10 oyuncu
ZREVRANK oyun_skor "ahmet"            # Ahmet'in sıradaki yeri

Atomik Rate Limiting — Sliding Window (Lua)

Node.js entegrasyonunda yukarıda gösterilen basit INCR + EXPIRE yaklaşımı çoğu API için yeterlidir, ama pencere sınırında hassasiyet kaybı yaşanabilir (iki komut arasında race condition riski teorik olarak vardır). Tamamen atomik bir kontrol için Lua script'i alternatiftir — mantığın tamamı Redis içinde tek adımda çalışır:

-- Lua script — atomik rate limit kontrolü
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current = redis.call('INCR', key)
if current == 1 then
  redis.call('EXPIRE', key, window)
end
if current > limit then return 0 end
return 1

EVAL veya önceden yüklenmiş haliyle EVALSHA ile çağrılır; sayaç artırma ve TTL kontrolü tek round-trip'te, bölünemez (atomik) şekilde yürür.

Pipelining ve Bağlantı Optimizasyonu

Pipelining

Her Redis komutu ayrı gönderildiğinde network round-trip gecikmesi birikir. Pipelining, birden çok komutu tek seferde gönderip yanıtları toplu almayı sağlar:

# Yavaş: her SET ayrı round-trip — 1000 komut ~10 sn sürebilir
for i in {1..1000}; do redis-cli SET key:$i $i; done

# Hızlı: pipelining ile aynı 1000 komut ~0.1 sn
seq 1000 | xargs -I {} echo "SET key:{} {}" | redis-cli --pipe

phpredis ve ioredis gibi sürücüler kendi pipelining API'sini sunar; toplu yazma/okuma işlemlerinde 50-100 kat hız artışı tipiktir.

Connection Pooling

// Node.js — ioredis (varsayılan tek bağlantı multiplexed çalışır, pool genelde gerekmez)
const redis = new Redis({
  host: '127.0.0.1',
  port: 6379,
  enableReadyCheck: true,
  maxRetriesPerRequest: 3,
});

// PHP — Predis persistent client (her istekte yeni TCP bağlantısı açmayı önler)
$pool = new Predis\Client([...], ['parameters' => ['persistent' => true]]);

Uyarı: KEYS * komutu production'da asla kullanılmamalı. Tüm keyspace'i tek seferde tarar; Redis tek thread çalıştığı için bu sırada diğer tüm komutlar bloklanır. Yerine cursor tabanlı SCAN kullanın — aynı işi keyspace'i küçük parçalar halinde, ana thread'i kilitlemeden tarayarak yapar.

Redis Cluster vs Sentinel

Redis Sentinel (Yüksek Erişilebilirlik)

Tek shard, yedekli mimari: master çökünce Sentinel otomatik replikayı (slave) master'a yükseltir. 3 Sentinel quorum (oy birliği) ile failover yönetilir. Tek VDS'ye sığan veri boyutunda yeterli; çoğu WordPress ve e-ticaret sitesi bu yapıyla rahat çalışır.

# /etc/redis/sentinel.conf
port 26379
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

İstemci doğrudan Redis'e değil Sentinel'lere bağlanır; güncel master'ın adresini Sentinel üzerinden öğrenir. Master, down-after-milliseconds (5000 ms) süresince yanıt vermez ve en az quorum (2) sayıda Sentinel hemfikir olursa, replica'lardan biri otomatik olarak yeni master'a yükseltilir.

Redis Cluster (Yatay Ölçekleme)

Veri 16.384 hash slot'a bölünerek birden fazla shard'a (tipik olarak 3 master + 3 replica, minimum 6 node) dağıtılır. Yüzlerce GB veri veya saniyede yüz binlerce istek gerektiğinde devreye girer. Kurulum ve yönetim Sentinel'e göre çok daha karmaşık; gerçek büyük ölçek olmadan tercih edilmez.

redis-cli --cluster create \
  192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 \
  192.168.1.13:6379 192.168.1.14:6379 192.168.1.15:6379 \
  --cluster-replicas 1

Cluster modunda çoklu anahtar komutları (MSET, transaction) yalnızca aynı hash slot'a düşen anahtarlarda çalışır. Aynı slot'a zorlamak için hash-tag notasyonu kullanılır — {} içindeki kısım hash hesaplamasına girer, geri kalanı yoksayılır:

SET {user42}:profil "..."
SET {user42}:sepet "..."
# İkisi de aynı slot'a düşer, çünkü hash yalnızca {user42} üzerinden hesaplanır

Büyükweb VDS sunucularında birden fazla VDS ile Sentinel veya Cluster üyeleri yapılandırılabilir; aynı veri merkezindeki düşük node-arası gecikme failover ve slot migration performansını doğrudan etkiler.

Monitoring — Redis İzleme

redis-cli INFO

# Genel durum
redis-cli INFO all

# Sadece bellek
redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation'

# Hit/miss oranı (en önemli cache metriği)
redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

# Anlık komut akışı (dikkat: yoğun trafikte performans etkiler)
redis-cli MONITOR

# Yavaş komut logu
redis-cli SLOWLOG GET 10
redis-cli CONFIG SET slowlog-log-slower-than 10000  # 10ms üzeri yakala

Hit Rate Hesaplama

redis-cli INFO stats | grep -E 'keyspace_hits|keyspace_misses'

%85 üzeri hit rate iyi; %70 altı cache stratejisini gözden geçirin (TTL çok kısa veya anahtar dağılımı çok geniş olabilir).

ACL ile Kullanıcı İzolasyonu (Redis 6+)

VDS'de birden fazla uygulama aynı Redis örneğini kullanıyorsa her birine ayrı kullanıcı ve anahtar prefix izni tanımlayın:

redis-cli ACL SETUSER uygulama1 on >sifre1 ~uygulama1:* +get +set +del +expire
redis-cli ACL SETUSER uygulama2 on >sifre2 ~uygulama2:* +get +set +del +expire
redis-cli ACL LIST

uygulama1 kullanıcısı yalnızca uygulama1:* anahtarlarına erişir; diğer uygulamaların verilerini göremez, değiştiremez.

Sıkça Sorulan Sorular

Redis mi Memcached mi? Hangisini tercih etmeliyim?

WordPress Object Cache için Redis zorunlu tercih (Memcached için uyumlu WP eklentisi yok). Genel cache için Redis daha yetenekli: persistence, veri tipleri, ACL, Pub/Sub Memcached'de yok. Sadece düz string cache ve çok yüksek paralel bağlantı (C10K+) gerektiğinde Memcached hâlâ geçerli. Yeni projeler için Redis başlayın.

Hangi Redis sürümünü kullanmalıyım?

Üretim ortamı için Redis 7.0 veya 7.2 LTS sürümleri 2026 itibarıyla önerilir — kararlı ve geniş desteklidir. Redis 8, daha önce ayrı modül olarak sunulan search ve JSON özelliklerini core'a taşıdı; yeni başlayan projelerde tercih edilebilir. Valkey (Redis'in BSD lisanslı fork'u) bazı bulut sağlayıcılarının sunduğu bir alternatif olarak öne çıkıyor; lisans tercihleri nedeniyle Redis yerine değerlendirilebilir.

Redis persistence açık olmalı mı, kapalı mı?

Cache-only kullanımda (veri kaybı önemsiz) persistence kapalı olabilir — bellek daha verimli kullanılır, restart hızlanır. Session veya queue tutuyorsanız AOF everysec açın. WordPress Object Cache için persistence genellikle kapalı: site restart olunca önbellek zaten geçersiz, sıfırdan dolar.

maxmemory-policy neyi etkiler?

Redis bellek dolduğunda hangi anahtarı sileceğini belirler. Saf cache için allkeys-lru (en az kullanılan gider) önerilir. Session gibi kritik veri için noeviction ayarlayın — bellek dolunca hata döner, silme olmaz. volatile-lru ikisi karışıksa: TTL olan cache silinir, TTL olmayan kalıcı veri korunur.

Küçük sitem için Redis kurmalı mıyım?

Günde 1000 ziyaretin altındaki blog veya kurumsal site için Redis kurulumu gereksiz karmaşıklık getirir. Büyükweb cPanel paketlerindeki LiteSpeed LSCache bu trafik için %95 yükü kapatır. Redis ihtiyacı yüksek dinamik sorgu, dağıtık session veya WebSocket gerektiren durumda ortaya çıkar.

Büyükweb cPanel'de Redis nasıl aktive edilir?

cPanel paylaşımlı hosting paketlerimizde Redis otomatik aktif değildir. PHP Redis eklentisi ve Redis sunucusu kullanıcı izolasyonuyla destek hattımız üzerinden talep bazlı aktive edilir. Destek için 0850 302 60 70'i arayabilir ya da my.buyukweb.com üzerinden ticket açabilirsiniz.

Redis Cluster ne zaman gerekir?

Tek sunucuya sığmayan veri boyutu (yüzlerce GB) veya saniyede yüz binlerce istek gerektiğinde. Orta büyüklükteki uygulamalar için Sentinel yeterli: master çökünce otomatik failover sağlar, cluster karmaşıklığı olmadan. Çoğu WordPress ve e-ticaret sitesi tek Redis örneğiyle yıllarca rahat çalışır.

Redis 6+ ACL ne işe yarar?

Aynı Redis sunucusunda birden fazla uygulama izole etmenizi sağlar: her uygulamaya farklı şifre, farklı anahtar prefix erişimi ve farklı komut izinleri tanımlarsınız. VDS'de tek Redis örneğiyle birden fazla proje çalıştırmanın güvenli yolu.

Redis'te veri sızıntısı riski var mı?

Varsayılan kurulumda Redis şifresiz ve tüm ağ arayüzlerine açık gelir. bind 127.0.0.1 ve requirepass mutlaka ayarlayın. Dışarıdan erişim gerekiyorsa TLS (Redis 6+) veya SSH tüneli kullanın. ACL ile uygulama bazlı izin kısıtlaması ekleyin.

---

İlgili Büyükweb Hizmetleri

Redis self-host için Türkiye lokasyonlu, root erişimli VDS sunucu paketlerimiz:

• VDS Sunucu
• E5 V4 VDS — ₺250/ay'dan, Redis için uygun başlangıç
• cPanel Web Hosting — Redis aktivasyonu destek hattından
• WordPress Hosting — LiteSpeed + LSCache standart
• Tüm Paketler — Karşılaştırma

Teknik destek ve Redis aktivasyonu için: 0850 302 60 70 veya iletişim sayfamız.