Redis DB Nedir? Mimari, Kullanım Alanları ve Yönetilen Redis Rehberi

Özet: Redis DB, in-memory key-value mimarisi üzerine kurulu, mikrosaniye seviyesinde gecikme ve saniyede 100.000+ komut işleme kapasitesi sunan bir veri yapısı sunucusudur. Cache, oturum yönetimi, mesaj kuyrukları, rate limiting ve leaderboard senaryolarında modern uygulamaların standart bileşeni. Üretim sınıfı kullanım için RDB + AOF persistence, Sentinel veya Cluster ile HA, TLS ve ACL ile güvenlik şarttır; KVKK kapsamında session verileri kişisel veri sayıldığından Türkiye veri merkezi tercihleri belirleyicidir.

Ana noktalar:
- Redis tek thread'li komut yürütücüsüyle deterministic, atomik işlemler ve mikrosaniye gecikme sağlar.
- Persistence için RDB + AOF hibrit kullanımı dakikalar mertebesinde RPO ile hızlı recovery sunar.
- Sentinel tek master + replica mimarisinde otomatik failover; Cluster 16.384 hash slot ile yatay ölçeklendirme yapar.
- Açık port 6379 ve requirepass yokluğu Shodan'da binlerce ihlal vakasının kaynağıdır.
- Yönetilen Redis (DBaaS), patching, HA kurulum ve monitoring yükünü ortadan kaldırarak TCO'yu çoğunlukla düşürür.

Modern uygulamaların performans omurgasında genellikle gözden kaçan ama kritik bir bileşen vardır: in-memory veri katmanı. Sepet açılışı 200 ms yerine 20 ms'de tamamlanıyorsa, bir oturum doğrulaması mikrosaniyelerde sonuçlanıyorsa veya rate limit kontrolü yüksek trafikte sistemi yavaşlatmıyorsa, sahnenin arkasında büyük ihtimalle Redis çalışıyordur. Redis bir cache aracı olarak başladı, bugün ise oturum yönetiminden mesaj kuyruklarına, leaderboard'lardan jeo-sorgulara kadar geniş bir iş yükü aralığını taşıyan tam bir veri yapısı sunucusu. Stack Overflow Developer Survey sonuçlarında Redis yıllardır en sevilen ve en çok kullanılan veritabanları arasında üst sıralarda yer alır.

Bu rehber, Türkiye'de B2B uygulama geliştiren backend ekipleri, mimar ve teknik liderler için yazıldı. Redis'in mimari avantajlarını, yaygın kullanım kalıplarını, üretim seviyesinde yüksek erişilebilirlik kurulumunu (Sentinel, Cluster) ve KVKK/BDDK çerçevesinde Türkiye'de Redis çalıştırmanın inceliklerini somut örneklerle ele alıyor. Kendi sunucunuzda Redis ile yönetilen Redis (DBaaS) arasındaki seçim için sayısal bir çerçeve de sunuyor.

Yazının sonunda, Redis'in projelerinizde nereye uyduğunu, hangi mimari kararların geri dönüşü zor olduğunu ve Cloud4U Türkiye DBaaS'in bu denklemde nasıl konumlandığını net göreceksiniz.

Redis nedir ve neden in-memory veritabanı kullanılır?

Disk tabanlı vs bellek tabanlı veritabanları

Klasik ilişkisel veritabanları (PostgreSQL, MySQL) verileri disk üzerinde tutar; her okuma diskten ya da işletim sistemi disk önbelleğinden gelir. Disk erişimi milisaniyeler düzeyindedir; aynı veriye saniyede on binlerce kez bakmak gerektiğinde bu maliyet hızla katlanır. In-memory veritabanları (Redis bunların en yaygını) tüm veriyi RAM'de tutar; tipik bir GET işlemi mikrosaniyelerde sonuçlanır.

Bu hız farkı yalnızca "daha hızlı" değil, mimari olarak farklı bir tasarımı mümkün kılar. İlişkisel sorgulardan beklenmeyen erişim sıklığını (saniyede 100.000+ GET) Redis kolayca karşılar. Veritabanı yerine değil, veritabanı önüne konumlanır — uygulamalar Redis'i ilk önce sorgular, miss durumunda PostgreSQL'e iner.

Redis'in mimari avantajları (latency (gecikme süresi), throughput (veri aktarım kapasitesi))

Redis tek thread'li bir komut işleyicisi olarak tasarlandı; bu, eşzamanlılık kilitleme karmaşıklığını ortadan kaldırır ve komut başına maliyeti minimize eder. Standart bir donanımda saniyede 100.000+ komut, küçük payload'larda mikrosaniye seviyesinde gecikme verir. Türk e-ticaret operatörlerinin kampanya pikleri sırasında Redis genellikle düşmeyen, ölçeklenmesi en kolay katmandır.

Redis 6 sonrası I/O thread'leri eklenmesiyle ağ katmanı paralelleşti; çekirdek komut yürütme yine tek thread ama I/O daha verimli hale geldi. Bu, modern Redis'i yüksek bağlantı sayılarında da güçlü kılıyor. Resmi Redis dokümantasyonu tüm komutlar, mimari ve yapılandırma için referans kaynağıdır.

Redis vs Memcached vs DragonflyDB

Memcached saf cache senaryosunda hâlâ yeterlidir ancak özellik fakirliği çoğu modern projeyi Redis'e yönlendirir. DragonflyDB yeni nesil bir Redis alternatifidir ve daha iyi vertical ölçekleme sunar; ekosistem ve araç desteği henüz Redis kadar olgun değildir.

Redis veri yapıları ve komutları

String, Hash, List, Set, Sorted Set

String basit anahtar-değer (en yaygın), Hash bir nesneyi (kullanıcı profili gibi) tek anahtar altında alan-değer çiftleriyle saklar. List FIFO/LIFO kuyruk olarak çalışır — basit job queue uygulamasında ideal. Set tekrarsız koleksiyon, kesişim/birleşim için kullanışlı. Sorted Set (ZSet) skor tabanlı sıralı koleksiyon — leaderboard, zaman tabanlı sıralama için biçilmiş kaftan.

Veri yapısı seçimi performans karakteristiğini doğrudan etkiler. Bir kullanıcı profilini 10 String anahtar yerine tek Hash içinde saklamak bellek tasarrufu ve atomic güncelleme avantajı sağlar.

Streams, HyperLogLog, Geospatial

Redis Streams, Kafka-benzeri append-only log yapısıdır; consumer group desteğiyle birden çok worker'ın paylaşımlı işlemesini sağlar. Hafif mesajlaşma ve event sourcing senaryolarında ayrı bir Kafka kümesi kurmaktan kaçınmak isteyen ekipler için iyi bir orta yol. Mesaj kalıcılığı, replay yeteneği ve ölü mektup (dead letter) işleme stratejileri uygulama tarafında kurulur.

HyperLogLog, probabilistik bir saymadır — milyarlarca farklı element içinde "kaç tane farklı X var" sorusuna %1 hata payıyla, çok az bellek tüketerek cevap verir. Tipik kullanım: günlük tekil ziyaretçi sayımı, benzersiz kampanya tıklamaları, A/B test grup boyutu — her birinin tam doğru sayıma ihtiyaç duymadığı, ancak terabyte seviyesinde veri tutmadan hızlı cevap vermesi gereken senaryolar.

Geospatial komutlar (GEOADD, GEORADIUS, GEOSEARCH) enlem-boylam tabanlı yakınlık sorguları için tasarlandı. Bir teslimat platformu kuryelerin anlık konumunu Redis'te tutar, müşteri sipariş verince "5 km içindeki uygun kuryeler" sorgusunu milisaniyelerde alır. Saha hizmetleri, mobilite ve gıda teslimatında pratik bir araç.

TTL, EXPIRE ve bellek yönetimi politikaları

Cache senaryolarında neredeyse her anahtarın bir TTL (Time To Live) değeri olmalı; EXPIRE key 3600 komutu bir saat sonra anahtarın silinmesini sağlar. Maksimum bellek dolduğunda Redis hangi anahtarları sileceğine maxmemory-policy ayarıyla karar verir: allkeys-lru (en eski kullanılan) en yaygın cache politikası; volatile-ttl TTL'i olan en erken sona erenleri siler. Yanlış politika seçimi sessiz veri kaybına yol açabilir — kritik veriler için noeviction kullanıp kapasite uyarısı kurmak doğru yaklaşım.

Kurumsal kullanım senaryoları

Önbellek (cache-aside, write-through, write-behind)

Cache-aside en yaygın desen: uygulama önce Redis'e bakar, miss ise PostgreSQL'e iner, sonucu Redis'e yazar. Sade ve net ama tutarlılık sorumluluğu uygulamada. Write-through her yazma hem Redis hem veritabanına gider — okuma tutarlılığı yüksek ama yazma latency (gecikme süresi) artar. Write-behind asenkron yazma — yüksek throughput (veri aktarım kapasitesi) ama veri kaybı riski vardır.

Çoğu Türk SaaS ekibi cache-aside ile başlar, kritik sıcak verilerde write-through ekler. Doğru desen veriye değil iş gereksinimine bağlıdır.

Oturum yönetimi ve token store

Web ve mobil uygulamalarda kullanıcı oturumları, JWT refresh token'ları, magic link kodları gibi kısa ömürlü ve yüksek okuma frekanslı veriler Redis'e konur. TTL otomatik temizliği sağlar; her okumada PostgreSQL'e gitmek gerekmediği için hem kaynak hem gecikme tasarrufu olur. Multi-instance backend mimarisinde paylaşımlı oturum store olmazsa olmazdır.

Pub/Sub ve mesaj kuyrukları

Redis Pub/Sub kanal tabanlı yayın-abone modelidir; düşük gecikmeli broadcast (canlı dashboard güncellemeleri, chat sistemleri) için iyi. Garanti edilmiş teslim gerekmiyorsa hafif bir çözüm. Garanti edilmiş teslim için Redis Streams + consumer group veya RabbitMQ/Kafka tercih edilir.

Rate limiting ve leaderboard

Redis atomic komutları (INCR, EXPIRE) basit ve sağlam rate limiter kurmanın temelidir. Saniye/dakika başına istek sayısını sayar, eşiği geçince 429 dönersiniz. Sorted Set tabanlı sliding window algoritması daha hassas kontrolü mümkün kılar. Leaderboard (oyun, kampanya, performans skoru) senaryolarında ZSet doğal çözümdür; milisaniyelerde top-100 sorgulanır.

Yüksek erişilebilirlik: Redis Sentinel ve Redis Cluster

Sentinel ile master-replica failover

Redis Sentinel, tek master + bir veya daha çok replica mimarisinde otomatik failover sağlar. Sentinel düğümleri (en az üç) master'ı izler; düşerse oy birliğiyle bir replica'yı promosyona alır. Uygulama Sentinel'i sorgulayarak güncel master'ı bulur. Tek master throughput (veri aktarım kapasitesi) sınırını aşmıyorsanız Sentinel HA için en pratik kurulum.

Cluster ile yatay ölçeklendirme ve sharding

Tek master'ın CPU veya bellek limitini aştığınızda Redis Cluster devreye girer. Veriler 16.384 hash slot arasında dağıtılır; her master küme bir slot aralığından sorumludur. İstemci kütüphaneleri MOVED/ASK yönlendirmelerini takip eder. Cluster modunda multi-key işlemler aynı slot'taki anahtarlara sınırlanır — uygulama tasarımı buna göre yapılmalı (hash tag kullanımı).

RDB ve AOF persistence stratejileri

RDB belirli aralıklarla snapshot çıkarır — hızlı yedek, hızlı geri yükleme; ancak iki snapshot arası veri kaybı riski. AOF (Append-Only File) her yazma komutunu log'a yazar — sıfır/minimal veri kaybı; ama dosya büyür ve yeniden başlatma yavaşlar. Üretim için yaygın yaklaşım: ikisi birden — her yazma appendfsync everysec ile AOF'a, günde bir RDB snapshot bulut yedekleme altyapısına / S3'e arşivlenir. Redis persistence dokümantasyonu yapılandırma örnekleri ve trade-off'lar için detaylı referanstır.

Redis güvenliği

ACL ve kullanıcı tabanlı yetkilendirme (Redis 6+)

Redis 6 öncesi sadece tek bir requirepass parolası vardı; herkes ya tam yetkili ya da yetkisizdi. Redis 6+ ACL ile kullanıcı bazlı yetki tanımlama, hangi komutların ve hangi key pattern'larının çalıştırılabileceğini kontrol etme imkanı sundu. Üretimde her servisin kendi kullanıcısı, sadece ihtiyacı kadar komut yetkisi olmalı. Salt admin parolası ile çalıştırmak büyük güvenlik açığı.

TLS şifreleme ve VPC izolasyonu

Redis 6 itibarıyla yerel TLS desteği eklendi. Üretimde istemci-sunucu trafiği TLS ile şifrelenmeli; sertifikalar Let's Encrypt ya da kurumsal CA üzerinden sağlanmalı. Redis sunucusu kesinlikle özel ağda (private network) tutulmalı; uygulama sunucularıyla aynı VPC içinde, dış internete kapalı.

Açık port 6379 — sık görülen güvenlik açığı

Shodan ve Censys gibi tarama servislerinde her gün binlerce açık Redis bulunur — requirepass ayarlanmamış, dünyaya açık. Saldırgan CONFIG SET dir /root/.ssh/ ve ardından authorized_keys yazma kombinasyonuyla sunucuyu ele geçirir. KVKK kapsamlı veri taşıyan bir Redis bu durumda doğrudan ihlal kapsamına girer. Üretim öncesi kontrol listesi: parola/ACL aktif, TLS aktif, port asla 0.0.0.0'a açık değil, CONFIG komutu sınırlı.

Yönetilen Redis (DBaaS) vs kendi sunucunuz

Yönetilen veritabanı modelinin temellerini bir DBaaS nedir yazısında bulabilirsiniz.

Bakım, yedekleme ve patch maliyeti

Redis kurulumu basit, ancak üretim sınıfı çalıştırmak farklı bir iş — patching, RDB/AOF yapılandırması, Sentinel/Cluster kurulumu, monitoring, alerting hepsi sizin sorumluluğunuzda. Yönetilen Redis bu yükü ortadan kaldırır; backup ve yükseltmeler sağlayıcı tarafından planlı yapılır.

SLA, RTO/RPO ve izleme

Yönetilen Redis genellikle %99.95+ uptime SLA'sı, RTO (recovery time objective) dakikalar mertebesinde, RPO (recovery point objective) saniyeler-dakikalar arasında sunar. Kendi yönetiminizde bu metriklere ulaşmak teknik mümkün ama operasyonel disiplin ve 7/24 kapsamlı izleme gerektirir.

Toplam sahip olma maliyeti (TCO) karşılaştırması

Aylık doğrudan altyapı maliyeti self-managed'de örnek olarak daha düşük görünür ama operasyonel insan maliyeti eklendiğinde yönetilen modelin TCO'su sıklıkla daha caziptir.

Türkiye'de Redis kullanımı: KVKK ve BDDK

Kişisel veri içeren session cache'ler ve KVKK

Session cache'leri çoğu zaman kullanıcı ID'si, tam ad, e-posta, son giriş zamanı gibi alanlar içerir — bu bilgiler KVKK kapsamındadır. Redis'in TLS aktif, ACL aktif, Türkiye veri merkezinde olması bu verinin koruma yükümlülüklerini karşılamada hayati. Yurt dışı bir yönetilen Redis kullanmak KVKK uyum süreçlerinde ek belge ve risk demektir.

Finansal sektör için BDDK gereklilikleri

Bankacılık ve ödeme servisleri BDDK çerçevesinde verinin yurt içinde tutulmasını, denetim loglarının saklanmasını ve segregation of duties prensiplerini ister. Redis'i bir cache veya rate limiter olarak kullanan finans uygulamaları için bu, sağlayıcı seçiminde belirleyici. Cloud4U Türkiye DBaaS gibi yerel yönetilen seçenekler bu çerçeveyi kolaylaştırır.

Türkiye veri merkezi ve düşük gecikme

Türkiye'deki son kullanıcıya hizmet veren uygulamaların Redis'i de Türkiye'de olmalı — coğrafi yakınlık 10-50 ms gecikme farkı yaratır. Frankfurt veya Amsterdam'da bir Redis ile İstanbul'daki uygulama arasındaki gecikme, milyarlarca komut çağrısı düşünüldüğünde anlam taşıyan bir performans farkıdır.

E-ticaret ve fintech için referans mimariler

Marketplace katalog cache'i

Türk marketplace'lerinin tipik mimarisinde ürün katalogu PostgreSQL'de, ürün detay sayfası okumaları Redis'te cache'lenir. TTL örnek olarak 5-15 dakika; ürün güncellendiğinde uygulama cache'i invalide eder. Bu mimari, kampanya günlerinde PostgreSQL'i 10x koruyucu bir tampon görür.

Ödeme servisi rate limiting

Ödeme API'larında kullanıcı başına saniyede X istek limiti Redis ile uygulanır; benzer şekilde DDoS koruma stratejilerini Redis tabanlı sayaçlarla tamamlayan ekipler vardır. Sliding window sayaç (ZSet üzerinde), her isteği zaman damgalı ekler, eski olanları temizler, aralık sayar. Limit aşıldığında 429 döner. Bu, kötü amaçlı denemeleri ve sistem aşırı yüklenmesini önler.

Bildirim kuyrukları (SMS / Push)

SMS, push notification, e-posta bildirimleri için Redis Streams hafif bir kuyruk olarak kullanılır. Uygulama notifications stream'ine event yazar; worker'lar consumer group içinde paylaşımlı işler. Ölü mektup kuyrukları, retry mantığı eklenir. Düşük-orta hacimlerde Kafka kurmanın karmaşıklığını gerektirmez.

Sıkça sorulan sorular (SSS)

Redis veriyi gerçekten kaybeder mi?

Redis, persistence kapalıyken veya yalnız RDB modundayken iki snapshot arasındaki veriyi kaybedebilir; AOF aktif ve appendfsync everysec ile en kötü ihtimalle 1 saniyelik veri kaybı olur. Üretimde AOF + günlük RDB snapshot kombinasyonu pratik standart kabul edilir; doğru yapılandırıldığında Redis production-grade kalıcılık sunar.

Redis Cluster'a ne zaman geçmeli?

Redis Cluster'a tek master'ın RAM veya CPU limitini zorladığınızda, single point of failure'dan kaçınmanız gerektiğinde ve veri 100+ GB ölçeğine ulaştığında geçilmelidir. Daha küçük yüklerde Sentinel HA + tek master yeterlidir; Cluster'a erken geçmek gereksiz operasyonel karmaşıklık doğurur.

Redis lisansı değişti mi, kullanmak hâlâ güvenli mi?

Evet, Redis 2024'te lisansını değiştirdi ancak çoğu kullanıcı için kullanım hâlâ güvenli ve yaygındır; bulut sağlayıcılarının yönetilen hizmet sunması açısından lisans sorumlulukları doğdu. Valkey (Linux Foundation altında BSD lisansı fork'u) ortaya çıktı. Çoğu projede Redis kullanımı sorunsuz; özel ticari durumlar için hukuk danışmanlığı önerilir.

Cache invalidation problemi nasıl yönetilir?

Cache invalidation üç ana stratejiyle yönetilir: TTL ile zaman bazlı geçersizlik, event-driven invalidation (veri değiştiğinde anahtar silmek) ve versiyonlama. TTL en basit; event-driven doğru ama uygulama disiplini ister; versiyonlama key'lere versiyon ekleyip eskileri TTL ile düşürür. Çoğu üretim sistemi bu üçünün bileşimini kullanır.

Cloud4U Türkiye DBaaS ile yönetilen Redis veritabanınızı dakikalar içinde başlatın

Redis'i kendiniz kurmak basit, ancak üretim sınıfı yüksek erişilebilirlik, güvenlik ve KVKK uyumunu kurmak ve sürdürmek farklı bir iş. Cloud4U Türkiye DBaaS, yönetilen Redis hizmetiyle bu yükü sizden alır, ekibinizin uygulamaya odaklanmasını sağlar.

Türkiye veri merkezi, KVKK uyumlu altyapı

• İstanbul veri merkezi — session, token ve cache verileri yurt içinde
• KVKK ve BDDK uyumlu altyapı — denetim için hazır belge ve loglar
• Düşük gecikme — Türkiye kullanıcılarınıza en kısa rota

Otomatik yedekleme, Sentinel HA, 7/24 izleme

• RDB + AOF persistence — yedekleme otomasyonu kutudan çıkar çıkmaz
• Sentinel master-replica HA — otomatik failover, manuel müdahalesiz
• TLS aktif, ACL hazır — güvenlik en iyi pratikleri varsayılan
• 7/24 izleme + Türkçe destek — gerçek mühendis kadrosu

Fiyatlandırma, ücretsiz deneme ve uzman desteği

Yönetilen Redis ihtiyacınızı somut bir teklife dönüştürmek, mevcut self-managed Redis'inizden geçiş planı almak veya ücretsiz deneme ortamı kurmak için Cloud4U Türkiye DBaaS sayfasını ziyaret edin. Ekibimiz, mimari değerlendirme ve KVKK/BDDK uyum danışmanlığı dahil uçtan uca süreç sunar.

İlgili içerikler

• Redis Nedir?
• DBaaS Nedir?
• PostgreSQL vs SQL Server