Önce Redis’teki veriyi sınıflandırın
Redis için en kritik soru şudur: Bu veri kaybolursa ne olur? Cevap “biraz yavaşlarız” ise önbellekten bahsediyorsunuz. Cevap “sipariş durumu bozulur, kullanıcı oturumu düşer, ödeme tekrar denenir” ise artık daha dikkatli bir kalıcılık kararı gerekir.
Kalıcılık ayarı yapmadan önce veri türlerini ayırmak gerekir. Aynı clusterda hem atılabilir önbellek hem de kritik kuyruk duruyorsa, ayarların kimin ihtiyacına göre yapılacağı belirsizleşir.
- Atılabilir önbellek: kaybolursa veritabanından yeniden üretilebilir.
- Oturum: kullanıcı deneyimini etkiler, iş kuralına göre kalıcılık isteyebilir.
- Sayaç ve limit bilgisi: kayıp güvenlik veya fatura etkisi yaratabilir.
- Kuyruk veya iş durumu: Redis tek başına doğru araç olmayabilir.
RDB ve AOF farkını sade düşünün
RDB belirli aralıklarla snapshot alır. Performans açısından hafiftir ama son snapshot sonrası yazılan veriler kaybolabilir. AOF ise yazma komutlarını dosyaya ekler; daha iyi geri dönüş sağlar ama disk ve gecikme etkisi vardır.
appendfsync ayarı bu dengenin kalbidir. always daha güvenlidir ama pahalıdır, everysec çoğu kullanım için pratik dengedir, no ise işletim sisteminin ne zaman yazacağına güvenir.
Redis kalıcılık ayarlarını okuma
redis-cli -u "$REDIS_URL" CONFIG GET appendonly redis-cli -u "$REDIS_URL" CONFIG GET appendfsync redis-cli -u "$REDIS_URL" CONFIG GET save redis-cli -u "$REDIS_URL" INFO persistence
Kalıcılık performans kararını da değiştirir
AOF açmak yalnızca güvenlik ayarı değildir; yazma gecikmesini ve disk kullanımını da etkiler. Çok sık yazılan sayaçlarda AOF büyümesi beklenenden hızlı olabilir. RDB ise fork sırasında bellek baskısı yaratabilir.
Bu yüzden Redis kalıcılık kararı kapasiteyle birlikte düşünülmelidir. Bellek doluluğu, yazma oranı, disk hızı ve yeniden başlama süresi aynı kararın parçalarıdır.
- AOF dosya büyümesi izlenmeli.
- RDB snapshot sırasında bellek baskısı ölçülmeli.
- Restart sonrası uygulama yeniden ısınma süresi bilinmeli.
- Kritik veri Redis dışında kalıcı kaynağa da yazılmalı.
Geri dönüş senaryosunu önceden yazın
Redis verisi kaybolduğunda ne yapılacağı olay anında düşünülmemeli. Önbellek ise yeniden ısıtma planı, oturum ise kullanıcı etkisi, kuyruk ise iş tekrar deneme davranışı yazılı olmalıdır.
“Redis yedeği var” cümlesi tek başına yeterli değildir. Hangi noktaya dönebiliyorsunuz, geri dönüş ne kadar sürüyor, eski veri uygulama davranışını bozuyor mu, bunlar ayrı ayrı test edilmelidir.
Redis veri sınıflandırma notu
Key deseni: Veri türü: önbellek / oturum / sayaç / kuyruk / kritik durum Kaybolursa etki: Yeniden üretilebilir mi: TTL var mı: AOF/RDB gereksinimi: Geri dönüş adımı: Test tarihi: