İçeriğe geç
Redis / Valkey

Redis (Remote Dictionary Server); bellek-içi key-value veri deposu olarak başlamış, zamanla veri yapıları sunucusuna dönüşmüştür. String, list, hash, set, sorted set, stream, geospatial, hyperloglog gibi zengin tipleri atomik komutlarla yönetir. 2024’te lisans değişikliği (BSD’den RSAL/SSPL’ye) sonrasında topluluk Valkey adıyla Linux Foundation altında forklamış; binary uyumlu olarak gelişimi sürdürmektedir.

Redis/Valkey’in en yaygın kullanım alanı uygulama cache’i olmasına rağmen, sistem mimarisinin neredeyse her köşesine girebilir: oturum deposu, hız sınırlama, kuyruklama (Lists/Streams), gerçek-zamanlı leaderboard (Sorted Sets), pub/sub, dağıtık kilit (Redlock), feature flag.

Mono’nun yaklaşımı

Mono kurulumlarında Redis/Valkey’in kararlı çalışması için aldığımız standart önlemler:

  • Lisans tercihi: Yeni kurulumlarda Valkey 7.2+; eski Redis kurulumlarını göç planı çerçevesinde Valkey’e taşıyoruz.
  • Topology: Sentinel (3 sentinel, 1 primary + 2 replica) varsayılan; sharding ihtiyacı doğrulanırsa Cluster.
  • Persistence: Cache rolünde kapalı; primary store rolünde AOF + everysec + cron RDB.
  • Network: TLS açık (Redis 6+), protected-mode yes, requirepass yerine ACL (Redis 6+).
  • Connection pooling: Uygulama tarafında pool boyutu çekirdek başına 4-8 (lazy-free + IO threads parametreleri ile uyumlu).
  • İzleme: redis-exporter + Grafana; key alarmlar: replication lag, blocked clients, evicted keys, memory frag ratio.

Tipik kullanım örüntüleri

  • Cache + DB pattern: Read-through veya cache-aside; TTL + jitter ile thundering herd kaçınma.
  • Rate limit: INCR + EXPIRE veya token bucket Lua script.
  • Distributed lock: Redlock algoritması (5 node majority); kısa TTL + heartbeat.
  • Session store: Web uygulamaları için TTL’li hash; oturum süresi politikasıyla otomatik temizlenir.
  • Job queue: Streams + Consumer Groups; legacy için Lists + BRPOPLPUSH.

Yaygın sorunlar ve çözümler

  • Slowlog’da KEYS *: Production’da bu komut yasak. ACL ile bloke edin; alternatif SCAN.
  • High memory frag: CONFIG SET activedefrag yes; uzun süreli kurulumlarda büyük yardımcı olur.
  • Replication lag: Primary’de büyük veri yapıları (LRANGE 0 -1) yavaş. Replica’da client-output-buffer-limit slave ayarı.
  • Eviction storm: Cache key’leri TTL’siz kalmış. Big key tespiti + maxmemory-policy doğru seçim.
  • Connection limit: maxclients artırılır ama asıl çözüm PgBouncer benzeri pool katmanı (Twemproxy / Envoy).

İlgili hizmetlerimiz

Sıkça sorulan sorular

Redis mi Valkey mi?
Yeni projeler için Valkey öneriyoruz: Redis’in 2024 lisans değişikliğinin (RSAL) ardından Linux Foundation altında forklanmış, BSD-3 lisanslı, Redis 7.2.4 ile ileri uyumlu. Mevcut Redis kurulumlarından geçiş binary uyumlu — sadece process’i değiştirmek yeterli.
Cluster mi Sentinel mi?
Sentinel master-replica modeli; tek shard, otomatik failover yeterliyse en sade çözüm. Cluster sharding ihtiyacı (50GB+ veri veya tek node bandwidth limiti) varsa şart. Ezici çoğunlukta Sentinel yeterli olur — Cluster operasyonel maliyeti yüksektir.
Persistence: AOF mi RDB mi?
Pure cache senaryosunda persistence kapalı olabilir (yeniden ısınır). Tek kaynak veri varsa (örn. job queue, oturum) AOF + everysec + günlük RDB snapshot. AOF rewrite için ayrı disk; bellek yoğun yazımlarda copy-on-write maliyeti unutulmamalı.
Bellek tükenmesi nasıl önlenir?
maxmemory + maxmemory-policy (genelde allkeys-lru cache, volatile-lru mixed). Key’lere mutlaka TTL koyun. Big key’leri tespit için redis-cli --bigkeys periyodik. Slowlog ile uzun süren komutları (örn. KEYS *) yasaklayın.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.