1. GİRİŞ

Redis (REmote DIctionary Server), modern bulut ve mikroservis uygulamalarında bellek içi (in‑memory) veri katmanı olarak yaygın kullanılan, yüksek performanslı bir açık kaynak anahtar‑değer veritabanıdır. Basit cache senaryolarından gerçek‑zamanlı veri akışlarına, mesaj kuyruğuna, sayım/istatistik toplama ve hatta coğrafi konum sorgularına kadar pek çok kullanım alanı vardır. Redis'in esnek veri yapıları, düşük gecikme, single‑threaded event loop mimarisi ve zengin persistence seçenekleri onu çeşitli performans/kullanılabilirlik ihtiyaçları için tercih edilir kılar.

Bu neden bugün önemli?

• Küresel kullanıcı tabanına sahip uygulamalarda düşük latency ve yüksek throughput ihtiyaçları arttı.
• Realtime uygulamalar (chat, oyun, bidding), analytics ve feature flags gibi kullanım alanları bellek‑içi veri katmanı gerektiriyor.
• Redis'in modüler ekosistemi (Redis Modules), vector search ve stream processing gibi yeni ihtiyaçları karşılayacak şekilde evriliyor.

Kimler için önemli?

• Backend geliştiriciler ve veri mühendisleri
• Platform mühendisleri, SRE ve DevOps ekipleri
• Gerçek zamanlı sistemler tasarlayan ekipler

Hangi problemleri çözüyor?

• Okuma‑ağırlıklı yüklerde veritabanı üzerindeki baskıyı azaltma
• Hızlı oturum yönetimi, rate limiting, leaderboards ve pub/sub gibi gerçek zamanlı işlevsellik
• Persistence seçenekleriyle veriyi bellek‑içi hızla sunarken veri kaybını minimize etme

2. KAVRAMSAL TEMELLER

2.1 Redis nedir — kısa tanım

Redis, C dilinde yazılmış, tek iş parçacıklı (single‑threaded) event loop ile çalışan, in‑memory veri deposudur. Anahtar‑değer mantığı temel olsa da liste, hash, set, sorted set, bitmap, hyperloglog ve more gibi zengin veri yapıları sunar. Redis, hafızada çalıştığı için yüksek hız sunar; aynı zamanda RDB/AOF persistence, replication ve clustering ile dayanıklılık ve ölçeklenebilirlik sağlar.

2.2 Temel veri yapıları

• String: En temel tip — genelde cache veya counter için kullanılır.
• Hash: Field‑value çiftleri, nesne benzeri yapıların tutulmasında pratiktir.
• List: FIFO veya LIFO davranışı sağlayan diziler; queue/stream benzeri kullanım.
• Set: Benzersiz eleman koleksiyonu — membership ve set operation'lar için etkili.
• Sorted Set (ZSET): Score ile sıralı küme — leaderboard, time‑series indexleme için kullanılır.
• Bitmap, HyperLogLog, Geo: Space‑efficient veri yapıları için optimize edilmiş özel tipler.

2.3 Mimari terimler

• Snapshotting (RDB): Periodik immutable disk snapshot'ları ile persistence sağlar.
• Append‑only file (AOF): Her yazma komutunu append ederek daha yüksek veri dayanıklılığı sağlar.
• Replication: Master‑Replica replikasyon ile read scaling ve failover mekanizmaları.
• Clustering: Veri sharding ile yatay ölçekleme; slot bazlı dağıtım (16384 slot).
• Eviction: Bellek sınırına ulaşıldığında hangi anahtarların atılacağını belirleyen policy.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Single‑threaded event loop ve I/O

Redis, tek bir ana döngüde (main loop) I/O ve komut yürütmesini yapar; bu tasarım CPU bound değil I/O bound düşük latency senaryolar için idealdir. Single‑threaded olması locking maliyetini ortadan kaldırır ve deterministik performans sağlar. Ağ I/O, pipeline, non‑blocking I/O ile verimli işlenir. CPU‑ağ dengesine bağlı olarak birden fazla Redis instance'ı veya cluster kullanmak gerekebilir.

3.2 Persistence: RDB ve AOF

Redis iki ana persistence seçeneği sunar:

• RDB (Snapshot): Belirli aralıklarda disk üzerinde tam snapshot alır. Startupta hızlı yüklenme sağlar fakat veri kaybı penceresi olabilir.
• AOF (Append‑only File): Tüm yazma komutlarını journal'a ekler; fsync politikası ile daha sıkı durability sağlanabilir. AOF dosyası zamanla rewrite edilerek küçültülür.

Production'da genelde RDB + AOF kombinasyonu tercih edilerek hem hızlı reboot hem de kabul edilebilir veri dayanıklılığı sağlanır.

3.3 Replication ve High Availability

Redis replication master‑replica modeline dayanır. Replica'lar master'dan asenkron olarak veriyi alır. Redis Sentinel veya Redis Cluster ile otomatik failover, health check ve replica promotion yönetilir. Sentinel, küçük footprint'li HA için kullanılırken, Cluster aynı zamanda yatay ölçekleme (sharding) sağlar.

3.4 Redis Cluster ve sharding

Redis Cluster, veriyi 16384 hash slot'a böler ve bu slot'ları node'lar arasında dağıtır. Her node belirli slot'ların sahibi olur; yazma ve okuma işlemleri slot hesaplaması ile doğrudan ilgili node'a yönlendirilir. Cluster mode, tek bir namespace içinde yatay ölçek sağlar fakat cross‑slot operasyonları kısıtlıdır; pipeline veya client‑side sharding özel durumlarda gerekir.

3.5 Memory management ve evictions

Redis'in performansı bellek yönetimi ile doğrudan ilişkilidir. Redis, jemalloc veya system allocator kullanarak bellek ayırır. maxmemory parametresi ile maksimum bellek sınırı belirlenir; eviction policy (noeviction, allkeys‑lru, volatile‑lru, volatile‑ttl, volatile‑random, allkeys‑random, allkeys‑lfu, volatile‑lfu) seçilerek hangi anahtarların atılacağı belirlenir. Bellek fragmentasyonu, büyük key'ler ve uzun lived object'ler operasyonel sorunlara yol açabilir.

3.6 Modules ekosistemi

Redis Modules API, geliştiricilerin Redis'e yeni veri yapıları ve özellikler eklemesine izin verir (örn. RedisJSON, RediSearch, RedisGraph, RedisBloom, RedisAI). Modüller sayesinde Redis sadece cache değil aynı zamanda full‑text search, graph DB, probabilistic structures ve ML inference gibi işlevleri de doğrudan sunabilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Popüler kullanım örnekleri

• Session store: Oturum bilgilerinin hızlı saklanması ve sorgulanması.
• Cache katmanı: Veri tabanı okuma maliyetini azaltmak için cache‑aside pattern yaygın.
• Rate limiting: Sliding window, token bucket ve counter tabanlı throttle mekanizmaları.
• Leaderboards / Sorted sets: Oyun ve puan tabloları için sıralı setler kullanılır.
• Pub/Sub ve Streams: Pub/Sub basit mesajlaşma için; Redis Streams ise durable stream processing ve consumer groups sağlar.
• Real‑time analytics: HyperLogLog, bitmap ve counters ile büyük veri özetleri tutulur.

4.2 Şirket ve örnekler

Birçok büyük şirket Redis'i cache ve real‑time işlevleri için kullanır: Twitter, GitHub, Pinterest, Snapchat gibi. Örneğin GitHub Actions ve job queue sistemlerinde Redis Streams/poplar kullanımı yaygındır; sosyal ağlar ise feed generation ve deduplication için Redis veri yapılarından faydalanır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Extremely low latency ve yüksek throughput — microseconds düzeyinde cevap süresi
• Zengin veri yapıları gerçek‑dünya problemlere doğrudan çözüm sunar
• Modüler yapı ve geniş ekosistem (Redis Enterprise, managed services)
• Persistence seçenekleri ile bellek‑içi hızda veri güvenliği sunma yeteneği

Sınırlamalar

• Bellek maliyeti: tam dataset bellek içinde tutuluyorsa maliyet artar
• Complex cross‑slot operasyonları ve multi‑key transaction'lar cluster ortamında sınırlıdır
• Yanlış persistence/eviction konfigürasyonu veri kaybına veya beklenmeyen davranışa yol açabilir

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Memory planning: maxmemory, reserved memory ve instance başına heap/OS ihtiyaçlarını hesaplayın.
• Eviction policy'leri iş mantığıyla uyumlu seçin (örn. allkeys‑lru veya volatile‑ttl).
• RDB + AOF kombinasyonu veya uygun fsync politikaları ile veri dayanıklılığını sağlayın.
• Cluster mode kullanırken slot‑aware client'lar (lettuce, Jedis, ioredis) tercih edin ve cross‑slot operasyonlarından kaçının.

Performans optimizasyonu

• Pipelining ve batching ile network RTT maliyetini azaltın.
• Hot key tespiti: sıklıkla erişilen anahtarları monitor edin, gerekirse replication veya dedicated node pinning uygulayın.
• Memory fragmentation için allocator seçimini (jemalloc) ve defragmentation opsiyonlarını değerlendirin.

Güvenlik

• Redis instance'larını private network/VPC içinde tutun, external erişimi TLS ve AUTH ile koruyun.
• ACL (Redis 6+) kullanarak per‑user / per‑client izinleri yönetin.
• Audit logging ve monitoring ile anomalileri tespit edin.

Observability

• Latency, ops/sec, connected_clients, memory, eviction ve persistence metriklerini toplayın.
• Slowlog, AOF/RDB rewrite events, replication lag gibi operational metriklerle RCA süreçlerini kolaylaştırın.

8. SIK YAPILAN HATALAR

• Her şeyi belleğe alarak maliyeti göz ardı etmek — dataset sizing ve cost analysis yapmadan production'a geçmek risklidir.
• AOF/RDB yapılandırmasını ihmal ederek veri kaybına neden olmak.
• Eviction policy'yi rastgele seçmek — iş mantığı ile uyumsuz evictionlar beklenmeyen hatalara yol açar.
• Cluster'ı tek client veya non‑slot aware client ile kullanmak — MOVED redirect hataları ve performans sorunları çıkar.

9. GELECEK TRENDLER

1. Vector search & RedisAI: Redis modülleri ile embedding tabanlı vektör arama ve ML inference to Redis'e entegre ediliyor.
2. Active‑active geo‑replication: Global uygulamalar için konflikt‑çözümleyici replikasyon modelleri ve CRDT‑like yaklaşımlar artacak.
3. Edge & serverless Redis: Daha lightweight, cold‑start tolerant Redis çözümleri ve managed edge dağıtımları gelişecek.
4. AI‑assisted tuning: Telemetriye dayalı otomatik memory, eviction ve persistence tuning araçları ortaya çıkacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Redis neden single‑threaded?

   Redis tek iş parçacıklı event loop kullanarak locking maliyetini ve yarış durumlarını azaltır; I/O bound, düşük latency hedefi için bu model sıklıkla daha verimlidir. CPU yoğun işler için yatay ölçek veya modüllerle çözüm gerekir.

2. 2. RDB mi AOF mi tercih etmeliyim?

   Genelde RDB (snapshot) hızlı reboot ve düşük disk IO avantajı, AOF ise daha sıkı durability sağlar. Production için RDB + AOF kombinasyonu ve uygun fsync politikaları önerilir.

3. 3. Redis Cluster ile cross‑slot işlem yapabilir miyim?

   Cross‑slot multi‑key komutlar cluster ortamında desteklenmez; bu operasyonlar ya aynı hash tag ile aynı slot'a yerleştirilmeli ya da client tarafında yeniden tasarlanmalıdır.

4. 4. Bellek sınırına ulaşıldığında ne olur?

   Redis maxmemory'a ulaştığında seçili eviction policy'ye göre anahtarlar atılır veya new writes reddedilir (noeviction). Bu davranış iş mantığına göre önceden belirlenmelidir.

5. 5. Redis'i cloud managed mi kullanmalıyım?

   Managed hizmetler (e.g., AWS ElastiCache, Azure Cache for Redis, Redis Enterprise) operasyonel yükü azaltır ve HA/backup gibi özellikleri kolaylaştırır; ancak maliyet ve vendor lock‑in faktörleri değerlendirilmeli.

6. 6. Hot key problemi nedir?

   Belirli bir anahtarın aşırı erişilmesi sonucu node'un CPU/memory/IO kaynaklarını tüketmesi. Çözüm olarak key partitioning, dedicated node veya read replica, cache tiering uygulanabilir.

7. 7. Redis modülleri güvenli mi?

   Resmi veya güvenilir modüller güvenlidir; ancak custom module yüklerken güvenlik, memory safety ve performans etkileri değerlendirilmelidir.

8. 8. Redis ile hangi metrikleri izlemeliyim?

   Ops/sec, latency p50/p95/p99, memory usage, fragmentation ratio, eviction rate, replication lag, connected clients, slowlog eventi gibi metrikler production izleme için kritik öneme sahiptir.

Anahtar Kavramlar

Eviction Policy

Bellek sınırına ulaşıldığında hangi anahtarların atılacağını belirleyen strateji (LRU, LFU, TTL vs).

RDB

Snapshot tabanlı persistence; belirli aralıklarla disk görüntüsü alır.

AOF

Append‑only journal; yazma komutlarını kaydederek daha dayanıklı persistence sağlar.

Redis Module

Redis işlevselliğini genişleten eklenti; örn. search, JSON, graph, bloom filtreleri.

Redis Streams

Durable, consumer group destekli stream veri yapısı; message queue ve event log kullanımına uygundur.

Öğrenme Yol Haritası

1. 0–1 ay: Redis temel komutları, veri tipleri (String, Hash, List, Set, ZSet) ve cache‑aside pattern öğrenin.
2. 1–3 ay: Persistence (RDB/AOF), replication, Sentinel ve basit clustering deneyimleri edinin; monitor metriklerini toplayın.
3. 3–6 ay: Production scaling: Redis Cluster, sharding stratejileri, memory tuning ve eviction design üzerinde çalışın.
4. 6–12 ay: Redis Modules (RediSearch, RedisJSON, RedisAI), streams ile event‑driven mimariler ve global active‑active senaryolarını deneyimleyin.