Redis ve Valkey, anahtarlarla erişilen veri yapılarını bellek içinde işleyen sunuculardır. Önbellek, oturum, hız sınırlama, sıralama ve bazı mesajlaşma örüntülerinde kullanılabilirler. Bu rollerin veri kaybı ve eviction (bellek sınırında anahtar çıkarma) politikaları aynı değildir. TTL, anahtarın ne zaman sona ereceğini; eviction ise bellek baskısında hangi anahtarların çıkarılabileceğini belirler.
Valkey, Redis OSS 7.2.4’ten türemiş ve bağımsız gelişen bir projedir. Ortak geçmiş, sonraki bütün sürümlerin komut, modül ve veri dosyası düzeyinde birebir aynı kalacağı anlamına gelmez.
Redis ile Valkey arasındaki lisans farkı
Redis’in resmi lisans açıklaması ve Valkey lisans dosyası sürüme bağlı okunmalıdır.
| Ürün/sürüm | Lisans kapsamı |
|---|---|
| Redis çekirdeği 7.2 ve öncesi | BSD-3-Clause |
| Redis 7.4 | RSALv2 veya SSPLv1; bunlar OSI onaylı açık kaynak lisansları değildir |
| Redis 8 | RSALv2, SSPLv1 veya AGPLv3 seçeneği |
| Valkey çekirdeği | BSD-3-Clause |
Redis 8’in AGPLv3 seçeneğini yok sayarak “Redis artık açık kaynak değil” demek güncel tabloyu yansıtmaz. Aynı şekilde Valkey’in çekirdek lisansı bütün modül ve yönetilen hizmetlerin koşullarını belirlemez. Karar; gereken özellikler, kullanım biçimi ve işletim sorumluluğuyla birlikte verilmelidir.
Cache, oturum ve kuyruk aynı şekilde işletilmez
- Cache: Ana veritabanından yeniden üretilebilen veri için TTL ve eviction politikası belirlenir. Toplu cache kaybının kaynak veritabanını aşırı yüklememesi planlanır.
- Oturum: Süre sonu, kullanıcı çıkışı ve güvenlik politikası birlikte ele alınır. Rastgele eviction kullanıcıların oturumunu etkileyebilir.
- Streams veya iş kuyruğu: Onay, yeniden teslim, tüketici durumu ve kalıcılık ayrı tasarlanır. Pub/Sub, kalıcı bir mesaj kuyruğu gibi değerlendirilmez.
- Dağıtık kilit: TTL veya tek bir atomik komut bütün hata senaryolarında iş doğruluğu sağlamaz; lease süresi, istemci duraklaması ve gerekirse fencing değerlendirilir.
Cache ile kaybedilmemesi gereken iş verisini aynı eviction politikası altında toplamak risklidir. Mesaj yönlendirme veya olayların yeniden okunması asıl ihtiyaçsa RabbitMQ ve Kafka da karşılaştırılmalıdır.
Sentinel mi Cluster mı?
Sentinel, primary-replica topolojisinde izleme, failover ve istemciye primary bilgisini sağlama görevlerini üstlenir. Veri sharding’i yapmaz. Sentinel üyeleri bağımsız hata alanlarına dağıtılır ve istemcinin Sentinel desteği doğrulanır.
Cluster ise veri ve trafiğin birden fazla shard’a dağıtılması gerektiğinde değerlendirilir. İstemci yönlendirmesi, çok anahtarlı işlemler ve anahtar dağılımı tasarımın parçasıdır. Ne Sentinel ne de Cluster, asenkron replikasyonun bütün veri kaybı pencerelerini ortadan kaldırır.
AOF, RDB ve bellek planı
Kalıcılık belgesi, RDB snapshot ile AOF kayıtlarının farklı geri dönüş özelliklerini açıklar. RDB, veri kümesinin belirli bir andaki snapshot’ını; AOF (Append-Only File), veri kümesini yeniden oluşturmak için yazma işlemlerinin kaydını tutar. fsync sıklığı, kaydın kalıcı depolamaya ne zaman aktarılacağını etkiler; veri kaybı hedefi ve disk yüküyle birlikte seçilir.
maxmemory, eviction politikası ve TTL uygulama rolüne göre belirlenir. Bütün anahtarlara koşulsuz TTL koymak veya bütün veriyi LRU ile atılabilir saymak doğru değildir. Fork/copy-on-write, replikasyon ve istemci buffer’ları için ek bellek payı gerekir.
Gecikme artışında büyük anahtarlar, uzun komutlar, ağ ve disk gecikmesi incelenir. KEYS * gibi tüm veri kümesini tarayan işlemler üretimde kontrolsüz kullanılmaz. SCAN kullanımı da veri büyüklüğü ve çağrı hızı açısından izlenmelidir.
Redis’ten Valkey’e geçiş planı
Resmi geçiş rehberi Redis OSS 7.2 ve öncesini temel alır; Redis CE 7.4 ve sonrası veri dosyalarının uyumlu olmadığını açıkça belirtir.
- Kaynak sürüm, modüller, kullanılan komutlar, Lua betikleri ve istemcileri çıkarın.
- Snapshot, replikasyon veya veri aktarım yönteminin sürüm çiftine uygunluğunu doğrulayın.
- Anahtar türleri, TTL, uygulama sonuçları ve yük altında gecikmeyi pilotta karşılaştırın.
- Son yazma işlemlerinin nasıl aktarılacağını ve istemcilerin ne zaman yönlendirileceğini belirleyin.
- Geri dönüş için uyumlu yedek ve yeni yazma işlemlerinin uzlaştırma planını koruyun.
