Redis Nedir? Cache, Session ve Kuyruk Rehberi

Redis nedir sorusunun en kısa cevabı şudur: bellekte çalışan, anahtar-değer mantığında, son derece hızlı bir veri deposudur. Açılımı Remote Dictionary Server olan Redis, verileri diskte değil RAM'de tuttuğu için okuma ve yazma işlemlerini mikrosaniyeler düzeyinde gerçekleştirir. Bu yazıda Redis'in neden bu kadar hızlı olduğunu, hangi durumlarda işe yaradığını ve bir web projesinde cache, session ve kuyruk için nasıl konumlandırıldığını pratik örneklerle anlatıyorum.

Redis nedir ve neden bu kadar hızlı?

Redis, geleneksel ilişkisel veritabanlarının (MySQL, PostgreSQL) yerine geçmek için değil, onların önüne hızlı bir katman koymak için tasarlanmıştır. Verinin tamamı bellekte tutulduğundan disk erişiminin gecikmesi ortadan kalkar. Buna birkaç temel özellik daha eklenir:

• Tek iş parçacıklı, olay tabanlı bir model kullanır; bu da kilit (lock) karmaşası olmadan saniyede yüz binlerce işlemi karşılayabilmesini sağlar.
• Sadece düz metin değil; liste, küme (set), sıralı küme (sorted set), hash ve sayaç gibi zengin veri yapıları sunar.
• İstenirse veriyi diske de yazarak (RDB anlık görüntüleri veya AOF günlüğü) yeniden başlatmaya karşı dayanıklılık sağlar.

Yani Redis sadece bir "cache" değildir; doğru kullanıldığında session deposu, kuyruk aracısı, gerçek zamanlı sayaç ve hatta basit bir mesajlaşma kanalı olabilir. Bu çok yönlülük, onu modern web mimarilerinde neredeyse standart bir bileşen hâline getirir. Tek bir Redis örneği aynı anda cache, session ve kuyruk görevlerini üstlenebilir; büyüdükçe bu sorumlulukları ayrı örneklere bölmek de mümkündür. Önemli olan, Redis'i veritabanının yerine değil tamamlayıcısı olarak konumlandırmaktır: kalıcı ve ilişkisel veri MySQL'de kalır, hız isteyen sıcak veri Redis'e taşınır.

Temel komutlar ve veri yapıları

Redis ile çalışmaya başlamanın en hızlı yolu komut satırı istemcisi redis-cli'dir. En sık kullanılan komutlar oldukça sezgiseldir:

SET kullanici:42:isim "Aslain"
GET kullanici:42:isim
EXPIRE kullanici:42:isim 3600   # 1 saat sonra otomatik silinsin
INCR sayfa:goruntuleme          # atomik sayaç
LPUSH kuyruk:mail "id:1001"     # listenin başına ekle
HSET urun:7 ad "Klavye" fiyat 450

Buradaki EXPIRE ve INCR komutları önemlidir. Otomatik süre dolumu (TTL), Redis'i cache için ideal kılar; atomik artırma ise yarış koşulu (race condition) olmadan sayaç tutmayı sağlar. Anahtar isimlerinde kullanici:42:isim gibi iki nokta ile ayrılmış bir konvansiyon kullanmak, veriyi mantıksal olarak gruplamayı kolaylaştırır.

Senaryo 1: Cache katmanı

Redis'in en yaygın kullanımı, pahalı sorguların veya hesaplamaların sonucunu saklamaktır. Mantık her zaman aynıdır: önce Redis'e bak, varsa oradan döndür; yoksa veritabanından hesapla, Redis'e yaz ve döndür. Laravel'de bu kalıp tek satıra iner çünkü cache sürücüsü olarak Redis'i seçtiğinizde tüm Cache API'si arka planda Redis'i kullanır:

# .env
CACHE_STORE=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

use Illuminate\Support\Facades\Cache;

$populer = Cache::remember('projeler:populer', now()->addHour(), function () {
    return Project::where('is_published', true)
        ->orderByDesc('views')
        ->take(10)
        ->get();
});

Bu yaklaşım, her sayfa yüklemesinde veritabanına giden ağır bir sorguyu saatte bir çalışacak hâle getirir. İlk istekte sonuç hesaplanıp Redis'e yazılır, sonraki tüm istekler bu hazır sonucu mikrosaniyeler içinde alır. Doğru anda temizlemek için ise Cache::forget('projeler:populer') kullanılır; içerik değiştiğinde bu satırı model olaylarına bağlamak en temiz çözümdür. Böylece veri her güncellendiğinde önbellek otomatik tazelenir ve kullanıcı asla bayat içerik görmez.

Senaryo 2: Session deposu

Tek sunuculu küçük projelerde session'ları dosyada tutmak sorun değildir. Ancak yük dengeleyici arkasında birden fazla sunucu çalıştığında, kullanıcı bir istekte A sunucusuna, diğerinde B sunucusuna düşebilir; dosya tabanlı session bu durumda kullanıcıyı sürekli oturumdan atar. Redis merkezi ve paylaşımlı bir session deposu olarak bu sorunu kökten çözer:

# .env
SESSION_DRIVER=redis

Artık tüm sunucular aynı Redis örneğinden session okur; kullanıcı hangi sunucuya düşerse düşsün oturumu kesintisiz devam eder. Aynı mantık sepet verisi, "beni hatırla" jetonları ve geçici kullanıcı durumları için de geçerlidir. Session'ların doğal olarak bir TTL'si olduğundan, Redis'in otomatik süre dolumu burada tam isabettir. Üstelik dosya tabanlı session'ların aksine, Redis'te eski oturumlar süresi dolunca kendiliğinden temizlenir; disk dolması veya binlerce küçük dosyanın birikmesi gibi sorunlarla uğraşmazsınız. Yatay ölçeklemeye geçmeyi düşünen her proje için bu, daha en başta atılması gereken sağlam bir adımdır.

Senaryo 3: Kuyruk ve arka plan işleri

Bir e-postanın gönderilmesi, görselin yeniden boyutlandırılması veya rapor üretilmesi gibi işler kullanıcıyı bekletmemelidir. Çözüm, bu işleri bir kuyruğa atıp arka planda işlemektir ve Redis bu iş için mükemmel bir aracıdır çünkü liste yapısı doğal bir kuyruk gibi davranır. Laravel'de yapılandırma yine basittir:

# .env
QUEUE_CONNECTION=redis

// İşi kuyruğa at — istek anında döner
SendWelcomeEmail::dispatch($user);

// Sunucuda işçiyi çalıştır
php artisan queue:work redis --tries=3

Burada dispatch çağrısı işi Redis listesine ekler ve isteği anında tamamlar; arka plandaki queue:work işçisi listeden işleri tek tek alıp çalıştırır. --tries=3 ile başarısız işler birkaç kez yeniden denenir. Bu desen, kullanıcı deneyimini hızlandırırken sunucu yükünü de zamana yayar.

Üretimde dikkat edilecekler

Redis güçlü olduğu kadar yanlış kullanıldığında sürpriz yapabilir. Birkaç pratik kural:

• Belleği izleyin. Redis RAM'de yaşar; sınırsız anahtar yazarsanız bellek dolar. maxmemory ve bir tahliye politikası (allkeys-lru gibi) ayarlayın.
• TTL vermeyi alışkanlık yapın. Süresiz yazılan cache anahtarları zamanla çöp birikimine dönüşür.
• Kalıcılık ihtiyacını netleştirin. Sadece cache için kullanıyorsanız veri kaybı önemsizdir; session ve kuyruk için AOF kalıcılığını açmak güvenlidir.
• Erişimi kapatın. Redis'i dış dünyaya açık bırakmayın; bind 127.0.0.1 ve bir parola (requirepass) temel güvenlik adımıdır.

Sık Sorulan Sorular

Redis ile Memcached arasındaki fark nedir?

Memcached yalnızca basit anahtar-değer önbelleği yapar. Redis ise liste, set, hash, sıralı küme gibi veri yapıları, kalıcılık, çoğaltma (replication) ve kuyruk/yayın-abone desenleri sunar. Sadece geçici cache için ikisi de iş görür; daha fazlasına ihtiyacınız varsa Redis çok daha esnektir.

Redis verileri kalıcı mı, yeniden başlatınca kaybolur mu?

Varsayılan olarak bellekte tutar ama kalıcılık seçenekleri vardır. RDB belirli aralıklarla disk anlık görüntüsü alır, AOF ise her yazma işlemini bir günlüğe yazar. İkisini birlikte kullanarak yeniden başlatmada veriyi geri yükleyebilirsiniz; saf cache senaryosunda bunları kapatmak da bir seçenektir.

Küçük bir proje için Redis şart mı?

Hayır. Tek sunuculu, düşük trafikli bir sitede dosya cache'i ve dosya session'ı fazlasıyla yeterlidir. Birden çok sunucu, yüksek trafik, gerçek zamanlı sayaçlar veya kuyruk ihtiyacı ortaya çıktığında Redis'e geçmek mantıklıdır.

Projenizi Redis ile hızlandırmak mı istiyorsunuz? Web uygulamanızın darboğazlarını birlikte ölçüp cache, session ve kuyruk için doğru Redis kurgusunu kuralım — benimle iletişime geçin.