Redis ölçeği çoğu zaman bellek ve key dağılımıdır
Redis’in performansı çok yüksek olduğu için sorunlar geç fark edilir. Bellek büyür, TTL’siz keyler birikir, tek kampanya keyi tüm trafiği çeker ve bir anda gecikme görünür hale gelir.
Bu yüzden Redis ölçek kararından önce key sayısı, bellek profili, eviction davranışı, network trafiği ve en çok erişilen keyler incelenmelidir.
Redis ölçek sinyalleri
redis-cli INFO memory redis-cli INFO stats redis-cli --hotkeys redis-cli --bigkeys
Hotkeys komutu örnekleme yapar; üretimde etkisi ve çalışma süresi dikkate alınmalıdır.
Cluster yatay büyütür, hot keyi sihirli biçimde çözmez
Redis Cluster keyleri slotlara dağıtır. Bu, toplam bellek ve işlem kapasitesini artırabilir. Ama tek key bütün trafiği alıyorsa o key hangi node’daysa sıcaklık orada kalır.
Hot key sorununda bazen keyi parçalamak, local cache kullanmak, TTL jitter eklemek veya veriyi farklı okuma modeline taşımak gerekir.
Cache düşerse ne olur sorusu ölçek sorusudur
Redis yalnızca hız katmanıysa, cache boşaldığında kaynak veritabanı bu yükü kaldırabiliyor mu? Eğer kaldıramıyorsa Redis ölçek sorunu aslında sistem ölçek sorunudur.
Cache stampede, aynı anda expire olan keyler ve yoğun kampanya trafiği bu yüzden önemlidir. Redis’i büyütmek yerine yenileme stratejisini düzeltmek daha doğru olabilir.
Kullanım örneği: kampanya sayfası açılıyor
Bir kampanya sayfasında aynı ürün listesi milyonlarca kez okunabilir. Tek key kullanılırsa hot key oluşabilir. Listeyi parçalara bölmek, CDN veya uygulama local cache eklemek ve TTL’i jitter ile dağıtmak baskıyı azaltır.
Stok ve fiyat gibi kritik alanlarda ise cache süresi kısa tutulmalı veya kaynak veritabanıyla tutarlılık beklentisi açık yazılmalıdır.