Redis Nedir, Hangi Durumlarda Kullanılır?

Modern yazılım mimarilerinde veri işleme hızı, kullanıcı deneyimini ve sistem ölçeklenebilirliğini doğrudan belirleyen en kritik parametredir. Geleneksel disk tabanlı ilişkisel veritabanları, yoğun okuma ve yazma talepleri altında yüksek disk giriş-çıkış (I/O) işlemleri nedeniyle performans darboğazı yaşayabilir. Bu noktada, milisaniye altı gecikme süreleriyle çalışan yüksek performanslı bir çözüm arayan mimarlar ve karar vericiler için Redis Nedir, Hangi Durumlarda Kullanılır? sorusu büyük önem kazanmaktadır. Bu teknik rehberde, Redis'in bellek içi mimarisini, veri yapılarını, kurumsal kullanım senaryolarını, operasyonel risklerini ve lisanslama detaylarını derinlemesine inceleyerek projeleriniz için doğru kararı vermenizi sağlayacağız.

Redis (Remote Dictionary Server) Nedir?

Bellek İçi (In-Memory) NoSQL Mimarisinin Temelleri

Redis (Remote Dictionary Server), Salvatore Sanfilippo tarafından 2009 yılında geliştirilmeye başlanan, verileri geçici bellekte (RAM) saklayan, açık kaynaklı ve yüksek performanslı bir bellek içi veri deposu (in-memory data store) teknolojisidir [1]. Geleneksel veritabanı yönetim sistemlerinin (DBMS) aksine, ana veri kümesini fiziksel diskler (SSD veya HDD) yerine doğrudan sunucunun sistem belleğinde tutar. Bu mimari tercih, veri erişim sürelerini mikro saniyeler düzeyine indirerek geleneksel disk tabanlı veritabanlarının fiziksel sınırlarını aşmasını sağlar.

Fiziksel disk erişimi, katı hal sürücülerinde (SSD) dahi mikrosaniye düzeyinde gecikmelere (latency) yol açarken, RAM tabanlı erişimler nanosaniyeler ölçeğinde gerçekleşir. Redis, bu fiziksel hız avantajını NoSQL mimarisiyle birleştirir. NoSQL yapısı sayesinde sabit bir tablo şemasına (schema) ihtiyaç duymaz ve verileri ilişkisel olmayan, esnek bir biçimde saklar. "Remote Dictionary Server" ismi, teknolojinin aslında ağ üzerinden erişilebilen ve paylaşılan devasa bir sözlük (hash table) gibi çalıştığına işaret eder.

Redis, basit bir anahtar-değer (key-value) eşlemesinin ötesine geçerek geniş bir veri yapıları (data structures) yelpazesi sunar. Bu esneklik, geliştiricilerin karmaşık veri modellerini doğrudan bellek üzerinde, ek bir işlem yükü getirmeden işlemesine olanak tanır. Çift yönlü listeler, sıralı kümeler, hash tabloları ve coğrafi indeksler gibi veri yapıları, Redis'in sadece bir önbellek (cache) mekanizması değil, aynı zamanda çok yönlü bir veri işleme motoru olarak konumlanmasını sağlar.

Neden Geleneksel Veritabanlarının Yerini Almaz?

Kurumsal sistem mimarilerinde sık yapılan hatalardan biri, Redis'in sunduğu yüksek performansa aldanarak onu birincil ve tek veritabanı (source of truth) olarak konumlandırmaya çalışmaktır. Ancak bu yaklaşım hem finansal hem de operasyonel açıdan büyük riskler barındırır. RAM, disk depolama birimlerine kıyasla gigabayt başına maliyet açısından son derece pahalı bir donanımdır. Terabaytlarca veriyi tamamen RAM üzerinde barındırmak, altyapı bütçelerini sürdürülemez kılabilir.

Bunun da ötesinde, RAM uçucu (volatile) bir bellek türüdür. Sunucuda meydana gelebilecek ani bir enerji kesintisi, donanım arızası veya işletim sistemi çökmesi durumunda, bellekteki tüm verilerin milisaniyeler içinde kaybolması riski mevcuttur. Redis, bu riski azaltmak amacıyla RDB ve AOF gibi veri kalıcılığı (persistence) mekanizmaları sunsa da, bu mekanizmalar geleneksel ilişkisel veritabanlarının (RDBMS) sunduğu mutlak veri tutarlılığı güvencelerini tam olarak sağlayamaz.

Geleneksel ilişkisel veritabanları (örneğin PostgreSQL veya MySQL), karmaşık ilişkisel sorguları (multi-table JOIN), gelişmiş indeksleme algoritmalarını ve ACID (Atomicity, Consistency, Isolation, Durability) standartlarına tam uyumlu transaction yapılarını desteklemek üzere tasarlanmıştır. Redis ise hız ve basitlik odaklıdır; ilişkisel sorguları veya deklaratif sorgu dillerini (SQL) desteklemez. Bu nedenle, modern mikroservis mimarilerinde Redis, ilişkisel veya doküman tabanlı ana veritabanlarının yerini almak için değil, onların üzerindeki okuma/yazma yükünü hafifleten tamamlayıcı bir performans katmanı olarak kurgulanmalıdır.

Redis Nasıl Çalışır ve Performansı Nereden Gelir?

Anahtar-Değer (Key-Value) Depolama Mantığı

Redis, en temel düzeyde bir anahtar-değer (key-value) depolama modeliyle çalışır. Sistemdeki her veri parçasına erişmek için benzersiz bir metinsel anahtar (key) kullanılır. Bu yapı, bilgisayar bilimlerindeki hash tablosu (hash table) prensibine dayanır. Hash tablosu kullanımı, arama, ekleme ve silme işlemlerinin zaman karmaşıklığının (time complexity) matematiksel olarak $O(1)$ yani sabit zamanlı olmasını sağlar. Bu sayede Redis içerisindeki anahtar sayısı milyonlara ulaşsa dahi, belirli bir anahtara erişim süresi değişmez.

Redis'in rakiplerinden ayrılan en güçlü yönü, değer (value) kısmında sadece düz metinler (string) değil, bellekte optimize edilmiş karmaşık veri yapıları (data structures) barındırabilmesidir. Bu yapılar doğrudan C dilinin veri tiplerine yakın bir optimizasyonla işlenir:

• Strings: En temel veri türüdür. İkili güvenli (binary-safe) olduklarından, düz metinlerden JPEG görsellerine veya serialize edilmiş JSON objelerine kadar her türlü veriyi 512 MB boyuta kadar saklayabilirler.

• Lists: Eklenme sırasına göre sıralanmış dizelerden oluşan çift yönlü bağlı listelerdir (linked lists). listenin başına (LPUSH) veya sonuna (RPUSH) eleman ekleme işlemleri $O(1)$ zaman karmaşıklığı ile çalışır, bu da onları kuyruk mekanizmaları için ideal kılar.

• Sets: Sıralanmamış ve benzersiz (unique) elemanlardan oluşan kümelerdir. İki küme arasındaki kesişim (SINTER), birleşim (SUNION) ve fark (SDIFF) gibi matematiksel işlemleri doğrudan sunucu tarafında çok hızlı bir şekilde gerçekleştirebilirler.

• Sorted Sets (ZSet): Her elemanın bir skor (score) değeriyle ilişkilendirildiği küme yapısıdır. Elemanlar skorlarına göre otomatik olarak sıralanır. Gerçek zamanlı liderlik tabloları (leaderboards) oluşturmak için biçilmiş kaftandır.

• Hashes: Alan-değer (field-value) çiftlerini içeren nesne benzeri yapılardır. Bir kullanıcının profil bilgilerini (ad, e-posta, rol) tek bir anahtar altında saklamak ve bu alanları bağımsız olarak güncellemek için mükemmel bir bellek optimizasyonu sunarlar.

• Streams: Redis 5.0 ile gelen, eklemeli log (append-only log) yapısıdır. Büyük miktarda gerçek zamanlı veri akışını tüketici grupları (consumer groups) mantığıyla işlemek için kullanılır.

Milisaniye Altı Gecikme (Sub-millisecond Latency) Kapasitesi

Redis'in saniyede yüz binlerce isteği milisaniye altı gecikme (sub-millisecond latency) ile yanıtlayabilmesinin arkasında benzersiz bir yazılım mühendisliği tasarımı yatar. Bu yüksek performans ve yüksek okuma/yazma hızı (throughput), temelde dört mimari sütuna dayanır:

1. Doğrudan Bellek Operasyonları: Veri erişimi sırasında hiçbir disk kafasının hareket etmesi, işletim sisteminin dosya sistemi sürücülerini çalıştırması veya disk önbelleklerini araması gerekmez. Tüm işlemler doğrudan RAM çiplerinin elektrik sinyalleri hızında gerçekleşir.

2. Tek İş Parçacıklı (Single-Threaded) Mimari: Birçok modern yazılımcı, yüksek performans için çoklu iş parçacığı (multi-threading) kullanımının zorunlu olduğunu düşünür. Ancak çoklu iş parçacığı kullanımı; işlemci çekirdekleri arasında sürekli bağlam değişimi (context switching) maliyeti yaratır ve veriye aynı anda erişmeye çalışan iş parçacıklarını koordine etmek için karmaşık kilit (mutex/lock) mekanizmalarına ihtiyaç duyar. Redis, tüm veri komutlarını tek bir ana iş parçacığı üzerinde sırayla çalıştırarak kilit bekleme sürelerini sıfıra indirir.

3. Giriş/Çıkış Çoklaması (I/O Multiplexing): Redis'in veri işleme motoru tek iş parçacıklı olsa da, ağ üzerinden gelen binlerce eş zamanlı bağlantıyı yönetmek için verimli I/O çoklama mekanizmaları (Linux'ta epoll, macOS/BSD'de kqueue) kullanır. Bu sistem, hazır olan ağ soketlerini tespit edip sırayla ana iş parçacığına besleyen son derece hızlı bir yönlendirici gibi çalışır.

4. ANSI C ile Sıfır Atık Yönetimi: Redis, donanıma en yakın dillerden biri olan ANSI C ile yazılmıştır [1]. Bellek yönetimi son derece agresif bir şekilde optimize edilmiştir. Java veya C# gibi dillerde performansı anlık olarak sabote edebilen otomatik bellek çöpü toplama (garbage collection) duraklamaları Redis dünyasında yaşanmaz.

Redis Hangi Durumlarda Kullanılır? (Kurumsal Kullanım Senaryoları)

Önbellekleme (Caching) ve Veritabanı Yükünü Azaltma

Redis'in dünya genelinde en çok tercih edildiği alan şüphesiz önbellekleme (caching) senaryolarıdır. Bir e-ticaret platformunda popüler bir ürünün detay sayfası, her saniye binlerce kullanıcı tarafından talep edilebilir. Eğer her istek için birincil ilişkisel veritabanına gidip karmaşık SELECT * FROM products JOIN categories... sorguları çalıştırılırsa, disk I/O limitleri hızla aşılacak, CPU kullanımı %100'e vuracak ve sistem yanıt veremez hale gelecektir.

"Cache-Aside" (Önbelleği Kenara Alma) tasarım deseniyle bu performans darboğazı kolayca çözülür. Uygulama, gelen isteği karşılamadan önce Redis'e gider ve talep edilen ürünün önbellekte olup olmadığını kontrol eder (Cache Hit). Eğer veri Redis'te mevcutsa, milisaniyeler içinde kullanıcıya döner. Eğer veri yoksa (Cache Miss), ana veritabanından sorgulanır, hazırlanan veri bir kopyasıyla birlikte Redis'e yazılır ve ardından kullanıcıya iletilir. Bu işlem sırasında veriye mutlaka bir TTL (Time to Live) yani yaşam süresi atanır. Böylece verinin sonsuza kadar RAM'de kalıp güncelliğini yitirmesi önlenir.

+-------------+         1. GET key          +---------------+
|             | --------------------------> |               |
|             | <-------------------------- |     Redis     |
|             |       2. Cache Hit          |               |
|             |      (Milisaniyelik)        +---------------+
|             |
|             |         3. Cache Miss (Veri Redis'te yoksa)
| Application | ------------------------------------+
|             |                                     |
|             |                                     v
|             |                             +---------------+
|             | <-------------------------- |   Primary     |
|             |         4. Query DB         |   Database    |
|             |                             | (PostgreSQL)  |
|             |         5. SET key          +---------------+
|             | --------------------------> (Yazma & TTL)
+-------------+

Kurumsal yapılarda kullanılan diğer önbellekleme stratejileri arasında "Write-Through" (Veriyi aynı anda hem cache hem de DB'ye yazma) ve "Write-Behind / Write-Back" (Veriyi önce hızlıca cache'e yazıp arka planda asenkron olarak DB'ye aktarma) yöntemleri yer alır. Bu sayede veritabanı sunucularının CPU kullanımı %90'lardan %10 seviyelerine kadar çekilebilir ve donanım maliyetlerinde ciddi tasarruf elde edilir.

Dağıtık Sistemlerde Oturum Yönetimi (Session Management)

Mikroservis mimarisi ve yük dengeleyicilerin (load balancer) arkasında çalışan çoklu sunucu yapılarında, kullanıcı oturumlarının (session) yönetilmesi teknik bir zorluk teşkil eder. Kullanıcı birinci sunucu üzerinden sisteme giriş yaptığında, sunucunun yerel belleğinde (in-memory state) oluşturulan oturum verisi, kullanıcının bir sonraki isteği ikinci sunucuya yönlendirildiğinde orada bulunamayacaktır. Bu durum, kullanıcının sürekli sistemden atılmasına neden olur.

Bu sorunu çözmek için Redis, merkezi bir oturum önbellekleme (session caching) deposu olarak konumlandırılır. Tüm uygulama sunucuları, gelen HTTP isteklerindeki session token'larını doğrulamak ve kullanıcı profil detaylarına erişmek için tek bir Redis kümesine (cluster) bağlanır.

// Node.js ve Redis ile Örnek Dağıtık Oturum Oluşturma ve TTL Tanımlama
const redis = require('redis');
const client = redis.createClient({ url: 'redis://localhost:6379' });

async function createSession(userId, sessionData) {
    await client.connect();
    const sessionKey = `session:${userId}`;
    
    // Oturum verisini JSON formatında kaydet ve 30 dakika (1800 saniye) TTL tanımla
    await client.set(sessionKey, JSON.stringify(sessionData), {
        EX: 1800
    });
    
    await client.disconnect();
}

Yukarıdaki basit entegrasyon örneği, kullanıcının oturum verisinin dağıtık sistemin her noktasından aynı hızda ve tutarlılıkla erişilebilir olmasını sağlar. Kullanıcı aktif hareket etmeye devam ettikçe TTL süresi arka planda yenilenerek oturumun canlı kalması sağlanır.

Gerçek Zamanlı Veri Analitiği ve Sayaçlar

Yüksek trafikli dijital platformlarda anlık tıklama oranları, sayfa görüntüleme sayıları veya canlı anket sonuçları gibi metrikleri ilişkisel veritabanlarında anlık olarak güncellemeye çalışmak, yoğun yazma kilitlenmelerine (row lock) neden olur. Redis, bu tür matematiksel ve istatistiksel işlemleri tamamen atomik düzeyde (atomic operations) bellek üzerinde gerçekleştirerek bu engeli aşar.

Redis'in INCR, DECR ve INCRBY gibi komutları, tek bir işlem döngüsünde bir anahtarın sayısal değerini artırır veya azaltır. Bu işlemler thread-safe (iş parçacığı güvenli) olduğu için, aynı milisaniyede gelen binlerce istek hiçbir veri kaybına veya çakışmaya yol açmadan sırayla işlenir.

Ayrıca Redis'in ZSET veri yapısı, gerçek zamanlı liderlik tabloları (leaderboards) oluşturmak için tasarlanmıştır. Örneğin, bir oyun platformunda veya e-ticaret sitesinde en çok satan ürünleri listelemek için ürün id'leri skorlarıyla birlikte bu kümeye eklenir. Redis, veriyi ekleme anında otomatik olarak sıraladığı için, "en yüksek skora sahip ilk 10 ürünü getir" sorgusu (ZREVRANGE) sistem üzerinde sıfır işlem yüküyle anında yanıtlanır.

Pub/Sub Mimarisi ile Anlık Mesajlaşma

Redis, uygulamalar arası asenkron iletişimi ve anlık veri dağıtımını kolaylaştırmak için yerleşik bir Pub/Sub (Publish/Subscribe - Yayınla/Abone Ol) mesajlaşma mimarisine sahiptir [1]. Bu mimaride, mesajı gönderen taraf (publisher) hedef alıcıları bilmeden belirli bir "kanala" (channel) mesaj gönderir. O kanala abone olan tüm istemciler (subscribers) ise mesajı anında teslim alır.

Bu yapı, özellikle finansal veri akışları, canlı spor skorları, borsa grafikleri ve gerçek zamanlı sohbet (chat) uygulamaları gibi anlık veri iletimi gerektiren sistemlerde kullanılır.

# Redis CLI üzerinden Pub/Sub kullanımı
# Terminal 1: Abone (Subscriber) kanalı dinlemeye başlar
SUBSCRIBE finance:stock_updates

# Terminal 2: Yayıncı (Publisher) kanala anlık borsa verisi gönderir
PUBLISH finance:stock_updates '{"symbol": "AAPL", "price": 178.50}'

Ancak Redis'in geleneksel Pub/Sub yapısının "at-and-forget" (gönder ve unut) prensibiyle çalıştığı unutulmamalıdır. Yani gönderilen mesaj o esnada çevrimdışı olan bir aboneye tekrar iletilmek üzere saklanmaz. Eğer mesajların kalıcı olması ve garantili teslimat (guaranteed delivery) gerekiyorsa, Redis Streams yapısı veya RabbitMQ/Kafka gibi özel mesaj kuyrukları tercih edilmelidir.

Kuyruk Yönetimi (Job Queues) ve Arka Plan İşlemleri

Kullanıcı arayüzünde hızlı yanıt verilmesi gereken web uygulamalarında, uzun süren işlemlerin (arka planda e-posta gönderimi, PDF faturası oluşturma, görsel boyutlandırma veya üçüncü taraf bir API entegrasyonuyla veri senkronizasyonu) ana HTTP thread'ini bloke etmesi engellenmelidir. Bu tür yoğun işlemler, asenkron olarak arka plan işçilerine (background workers) devredilmelidir.

Redis'in list veri yapıları, güvenilir mesaj kuyrukları oluşturmak için mükemmel bir altyapı sunar. Ana uygulama, yapılacak işi bir JSON objesi haline getirerek Redis listesinin sonuna ekler (RPUSH). Arka planda sürekli çalışan worker servisleri ise listenin başından komutları sırayla çekerek (LPOP veya bağlantıyı bloke ederek yeni eleman bekleyen BLPOP) işleri sırayla tüketir. Node.js ekosistemindeki BullMQ veya Python dünyasındaki Celery gibi popüler dağıtık görev kuyruğu kütüphaneleri, arka planda tamamen Redis'in bu hızlı kuyruk yeteneklerini kullanmaktadır.

Kurumsal Yapılarda Redis Kullanımında Dikkat Edilmesi Gereken Riskler

Bellek (RAM) Maliyetleri ve Kapasite Planlaması

Redis, tüm veri kümesini RAM üzerinde tuttuğu için kapasite planlaması kurumsal projelerde en kritik operasyonel aşamadır. Disk tabanlı sistemlerde depolama alanı dolduğunda ek bir NVMe SSD eklemek oldukça düşük maliyetliyken, RAM kapasitesini artırmak hem fiziksel donanım mimarisinin sınırlarına takılır hem de bulut sağlayıcılarında (AWS, Azure, GCP) maliyetlerin katlanarak artmasına yol açar.

Kapasite planlaması yapılırken sadece saklanacak ham verinin boyutu değil, Redis'in bu veriyi RAM'de tutmak için kullandığı C veri yapılarının getirdiği ek yük (overhead) de hesaba katılmalıdır. Ayrıca, işletim sisteminin bellek tahsisatçısı (genellikle jemalloc) tarafından oluşturulan bellek parçalanması (memory fragmentation) nedeniyle, Redis'in gerçekte kullandığı RAM miktarı, verinin boyutundan daha fazla olabilir.

Bir diğer hayati kural ise, sunucu RAM'inin asla %100 kapasiteyle doldurulmaması gerektiğidir. Redis arka planda veri kalıcılığı yedeklemesi yaparken işletim sisteminin fork() sistem çağrısını kullanır. Copy-on-Write (COW) mekanizması nedeniyle, yoğun yazma alan sistemlerde yedekleme esnasında RAM kullanımı geçici olarak iki katına çıkabilir. Bu durum, sistemde yeterli boş alan kalmadığında işletim sisteminin "Out of Memory (OOM) Killer" mekanizmasının Redis sürecini aniden sonlandırmasına neden olur. Güvenli bir üretim ortamı için fiziksel belleğin en az %30 ila %40'ının her zaman boş bırakılması önerilir.

Veri Kalıcılığı (Persistence): RDB ve AOF Stratejilerinin Sınırları

Redis, bellek tabanlı olmasının getirdiği uçuculuk (volatility) riskini en aza indirmek için iki temel veri kalıcılığı (persistence) yöntemi sunar:

• RDB (Redis Database Backup): Belirlenen zaman aralıklarında (örneğin "son 15 dakikada en az 10 anahtar değiştiyse") bellekteki verinin anlık bir görüntüsünü (snapshot) sıkıştırılmış bir dosya olarak diske yazar.

• _Avantajı:_ Dosya boyutu küçüktür, sunucu çöktüğünde geri yükleme işlemi son derece hızlıdır.

• _Riski:_ İki yedekleme döngüsü arasında meydana gelen çökmelerde, son yedeklemeden sonra yazılan tüm veriler tamamen kaybolur. Finansal işlemler için bu durum kabul edilemez.

• AOF (Append Only File): Sunucuya gelen her yazma komutunu sırayla bir log dosyasına yazar. Sunucu yeniden başladığında bu komutları baştan oynatarak veri kümesini yeniden inşa eder.

• _Avantajı:_ fsync ayarına bağlı olarak (her saniye veya her komutta bir) veri kaybı riski neredeyse sıfıra indirilir.

• _Riski:_ Log dosyası çok hızlı büyür. Dosya boyutunu optimize etmek için arka planda çalışan BGREWRITEAOF işlemi yüksek CPU ve disk I/O yükü oluşturur.

Kurumsal mimarilerde genellikle her iki yöntemin bir arada kullanıldığı hibrit model tercih edilir. Ancak her iki senaryoda da disk yazma işlemlerinin Redis'in milisaniye altı gecikme sürelerini bloke etmemesi için disklerin yüksek hızlı NVMe standardında olması şarttır.

Tek İş Parçacıklı (Single-Thread) Yapının Getirdiği Darboğazlar

Redis'in tek bir iş parçacığı üzerinden çalışması, kilit mekanizmalarını ortadan kaldırarak hızı artırsa da, hatalı tasarlanmış komutların tüm sistemi felç etmesine yol açabilir. Çünkü tek bir işlemcinin koşturduğu bu döngüde, çalışması uzun süren bir komut bitene kadar arkasından gelen binlerce okuma ve yazma talebi sırada beklemek zorunda kalır.

Bunun en klasik örneği, sistemdeki tüm anahtarları listelemek için kullanılan KEYS * komutudur. Milyonlarca anahtarın bulunduğu bir kurumsal üretim ortamında bu komutun çalıştırılması, Redis'in saniyelerce kilitlenmesine neden olur. Bu süre zarfında uygulama sunucuları Redis'ten yanıt alamadığı için zaman aşımına (timeout) uğrar ve web sitesi çöker.

# ASLA KULLANMAYIN (Sistemi bloke eder):
KEYS user:session:*

# BUNUN YERİNE TERCİH EDİN (Non-blocking / İteratif tarama):
SCAN 0 MATCH user:session:* COUNT 100

Benzer şekilde, çok büyük boyutlu bir Sorted Set veya Hash yapısını tek seferde silmeye çalışmak da (DEL) sistemi bloke edebilir. Bu tür işlemler için Redis 4.0 ile gelen asenkron silme komutu UNLINK tercih edilmelidir. UNLINK, anahtarın bellekten hemen kaldırılmasını sağlarken, arka planda belleğin asıl temizlenme sürecini farklı bir iş parçacığına devrederek ana döngüyü rahatlatır.

Veri Tahliyesi (Eviction) Politikalarının Doğru Seçilmesi

Redis için ayrılan bellek limiti (maxmemory parametresi) tamamen dolduğunda ve yeni bir veri yazılmaya çalışıldığında ne olacağı, yapılandırılan veri tahliyesi (eviction) politikasına bağlıdır. Doğru politikanın seçilmemesi, kurumsal uygulamaların çökmesine veya kritik verilerin beklenmedik şekilde silinmesine neden olabilir.

Sistem yöneticileri maxmemory-policy ayarı altında şu temel seçeneklerden birini seçmelidir:

1. noeviction (Varsayılan): Bellek dolduğunda yeni yazma işlemlerine hata döner, ancak mevcut verileri silmez. Önbellekleme için son derece tehlikelidir; uygulamanın hata vermesine neden olur.

2. allkeys-lru (Least Recently Used): Bellek dolduğunda, tüm anahtarlar arasından en uzun süredir erişilmeyen (en eski) verileri silerek yeni verilere yer açar. Standart önbellekleme senaryoları için en güvenli ve önerilen modeldir.

3. volatile-lru: Sadece yaşam süresi (TTL/expire) tanımlanmış olan anahtarlar arasından en eski olanları siler. Eğer oturum verileri gibi silinmemesi gereken veriler ile önbellek verileri aynı Redis örneğinde tutuluyorsa, bu politika hayati önem taşır.

Hangi politikanın seçileceği, Redis'in kullanım amacına göre belirlenmelidir. Eğer Redis saf bir önbellek olarak kurgulandıysa allkeys-lru seçilebilir; ancak kalıcı olması gereken oturum verileri barındırılıyorsa, yanlışlıkla bu verilerin silinmesini önlemek için bellek doluluğu yakından izlenmeli ve tahliye stratejisi özenle kurgulanmalıdır.

Redis ve Alternatiflerinin Karşılaştırması

Redis vs. Memcached: Hangisi Tercih Edilmeli?

Bellek içi önbellekleme denildiğinde akla gelen en eski ve popüler alternatiflerden biri Memcached'dir. Her iki teknoloji de RAM tabanlı çalışarak yüksek hız sunsa da, mimari felsefeleri ve sundukları yetenekler açısından keskin ayrılıklara sahiptirler.

Memcached, çok iş parçacıklı (multi-threaded) bir yapıya sahiptir. Bu sayede, çok çekirdekli modern sunucuların gücünü dikey ölçeklendirme (vertical scaling) ile tek bir örnekte sonuna kadar kullanabilir. Sadece basit anahtar-değer (string) saklama amacına hizmet eder. Verileri işleme veya karmaşık sorgulama yetenekleri yoktur. Veri kalıcılığı (persistence) sunmaz; sunucu kapandığında tüm veriler tamamen kaybolur.

Redis ise tek iş parçacıklı olmasına rağmen sunduğu zengin veri yapıları, replikasyon yetenekleri, Sentinel ile otomatik kurtarma mekanizmaları ve disk yedekleme desteğiyle Memcached'in çok ötesindedir. Basit ve statik HTML bloklarını veya küçük sorgu sonuçlarını önbelleğe almak için Memcached hala geçerli bir alternatif olsa da; oturum yönetimi, kuyruk mekanizmaları ve dinamik veri manipülasyonu gerektiren modern kurumsal projelerde Redis tartışmasız galip gelmektedir.

Redis vs. İlişkisel Veritabanları (PostgreSQL, MySQL vb.)

İlişkisel veritabanları (RDBMS), verileri katı şemalar, tablolar, satırlar ve yabancı anahtarlar (foreign keys) üzerinden organize eder. Ana odakları, verinin her ne koşulda olursa olsun güvenli, tutarlı ve sorgulanabilir bir şekilde diskte saklanmasıdır. Bu durum, her veri okuma ve yazma işleminde yoğun disk erişimi ve ACID işlem kilitleri anlamına gelir.

Redis ise hızı ve veriye en hızlı şekilde erişmeyi hedefler. Verileri organize etmek için tablolar yerine bellek içi veri yapılarını kullanır. İlişkisel veritabanlarının sunduğu karmaşık çoklu tablo birleştirme (JOIN) işlemlerini yapamaz.

Aşağıdaki tablo, kurumsal karar vericilerin bu iki mimari arasındaki farkları net bir şekilde görebilmesi için hazırlanmıştır:

Redis Yatırımı Yapmadan Önce Değerlendirilmesi gereken Kritik Kriterler

Lisans Değişikliği ve Açık Kaynak Dünyasındaki Gelişmeler

Kurumsal düzeyde Redis yatırımı yapacak şirketlerin bilmesi gereken en önemli idari değişiklik, Redis'in lisanslama politikasında gerçekleşmiştir. Mart 2024 itibarıyla Redis, geleneksel özgür BSD 3-Clause lisansından vazgeçerek, kaynak kodu erişilebilir ancak ticari kısıtlamaları olan çift lisanslı (RSALv2 ve SSPLv1) bir modele geçiş yapmıştır.

Bu yeni lisans modeline göre, Redis'in güncel sürümlerini kendi sunucularında (on-premise) veya kendi uygulamalarının arkasında kullanan işletmeler için herhangi bir ücret ödeme zorunluluğu bulunmamaktadır. Ancak, Redis'i bulut üzerinden doğrudan ticari bir "Yönetilen Hizmet" (Managed Service) olarak satmak isteyen bulut sağlayıcıları artık Redis Ltd. ile ticari anlaşmalar yapmak zorundadır.

Bu lisans değişikliğine tepki olarak, Linux Vakfı (Linux Foundation) öncülüğünde, AWS, Google Cloud, Oracle ve Ericsson gibi teknoloji devlerinin desteğiyle tamamen açık kaynaklı ve BSD lisanslı Valkey adında bir alternatif geliştirilmeye başlanmıştır. Karar vericilerin, uzun vadeli altyapı stratejilerinde lisans maliyetlerinden ve kısıtlamalarından kaçınmak adına, projelerinde standart Redis yerine tamamen açık kaynaklı kalan Valkey projesini de bir alternatif olarak masada bulundurması stratejik bir vizyon gereğidir.

Yüksek Erişilebilirlik (High Availability) ve Ölçeklenebilirlik

Üretim ortamındaki kurumsal bir Redis mimarisinin tek bir sunucu üzerinde (single instance) çalıştırılması, o sunucunun çökmesi durumunda tüm sistemin durmasına yol açan tek bir başarısızlık noktası (Single Point of Failure - SPOF) yaratır. Kesintisiz bir hizmet sunmak (SLA oranlarını korumak) için şu iki yüksek erişilebilirlik ve ölçekleme mimarisinden biri kurulmalıdır:

1. Redis Sentinel (Yüksek Erişilebilirlik): Sentinel, bir ana (primary) ve birden fazla yedek (replica) Redis düğümünü sürekli izler. Ana düğümde bir donanım arızası veya çökme yaşandığında, Sentinel düğümleri kendi aralarında oylama yaparak otomatik olarak yedek düğümlerden birini yeni "ana düğüm" ilan eder (Automatic Failover). Veri boyutunun tek bir sunucunun RAM kapasitesini aşmadığı, ancak kesintisizliğin kritik olduğu durumlar için idealdir.

2. Redis Cluster (Yatay Ölçeklenebilirlik ve Sharding): Veri boyutu tek bir sunucunun fiziksel RAM limitlerini aştığında veya saniyede milyonlarca yazma isteği geldiğinde, verileri birden fazla ana sunucuya bölüştürmek (sharding) gerekir. Redis Cluster, verileri 16.384 sanal slota bölerek farklı fiziksel sunuculara dağıtır. Böylece hem bellek kapasitesi hem de yazma kapasitesi yatayda limitsiz bir şekilde ölçeklenebilir.

                  +--------------------------------+
                  |         Application Client     |
                  +--------------------------------+
                     /             |            \
       Slots: [0-5460]      Slots: [5461-10922]  Slots: [10923-16383]
                   /               |              \
                  v                v               v
           +--------------+ +--------------+ +--------------+
           | Redis Node A | | Redis Node B | | Redis Node C |
           |  (Primary)   | |  (Primary)   | |  (Primary)   |
           +--------------+ +--------------+ +--------------+
                  |                |                |
             (Replication)    (Replication)    (Replication)
                  v                v               v
           +--------------+ +--------------+ +--------------+
           | Redis Node A | | Redis Node B | | Redis Node C |
           |  (Replica)   | |  (Replica)   | |  (Replica)   |
           +--------------+ +--------------+ +--------------+

GDPR ve KVKK Kapsamında Veri Güvenliği Yönetimi

Redis, hız odaklı yapısı gereği varsayılan kurulum ayarlarında güvenlik mekanizmalarını arka plana iter. Örneğin, varsayılan kurulumda herhangi bir şifre koruması olmadan 6379 portundan dış dünyaya açık şekilde çalışabilir. Bu durum, siber saldırganların açık portlar üzerinden bellek verilerini kolayca sızdırmasına (data leak) neden olur.

Avrupa Genel Veri Koruma Yönetmeliği (GDPR) ve Türkiye'deki Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında, kullanıcıların kişisel verilerinin (e-posta adresleri, telefon numaraları, kimlik bilgileri, oturum token'ları) güvenli bir şekilde saklanması yasal bir zorunluluktur. Bellek içi veri deposu üzerinde saklanan geçici veriler de bu yasaların kapsamına girmektedir.

Redis üzerinde güvenliği sağlamak için şu adımlar zorunlu olarak uygulanmalıdır:

• Port Koruması ve Bağlantı Sınırlandırması: Redis sunucusu dış dünyaya tamamen kapatılmalı, sadece localhost veya güvenli bir iç ağdan (VPC) gelen bağlantıları kabul edecek şekilde (bind 127.0.0.1 veya yerel IP adresi) yapılandırılmalıdır.

• Güçlü Kimlik Doğrulama ve ACL (Access Control Lists): Redis 6.0 ile birlikte gelen gelişmiş ACL mekanizması kullanılmalıdır. Her mikroservise sadece ihtiyaç duyduğu anahtar kalıplarına erişebileceği, sınırlı yetkilere sahip özel kullanıcı hesapları tanımlanmalıdır.

• Transit Veri Şifreleme (TLS): Uygulama sunucuları ile Redis arasındaki veri trafiği, ağ üzerinden dinlenmeye (sniffing) karşı TLS şifrelemesiyle korunmalıdır.

• Kişisel Verilerin Maskelenmesi: Oturum veya önbellek amacıyla Redis'e yazılacak kişisel veriler, belleğe aktarılmadan önce uygulama katmanında güçlü kriptografik algoritmalarla (AES-256) şifrelenmeli veya hash'lenmelidir. Unutulmamalıdır ki, RAM üzerindeki veriler de siber saldırganlar tarafından "RAM Dump" yöntemleriyle okunabilir.