Redis cache stampede'i (thundering herd) nasıl önlerim — mutex lock mı, XFetch mi?
Soru
Yoğun trafikli bir e-ticaretin ana sayfa ürün listesini Redis'te 10 dk önbelleğe alıyoruz. Önbellek tam expire olduğu saniyede gelen binlerce eşzamanlı istek cache miss alıp aynı anda PostgreSQL'e yükleniyor ve DB'yi çökertiyor. Bu cache stampede'i çözmek için mimari düzeyde mutex lock veya probabilistic early expiration (XFetch) algoritmalarını nasıl uygularım?
Cevap
Kısa cevap: Sorun “miss”in kendisi değil, anahtarın aynı saniyede uçurumdan düşmesi ve tüm sürünün aynı anda DB’ye yüklenmesi. Çözüm, o ânı tek isteğe indirgemek ve sürüyü zamana yaymak.
Kısa cevap
Yaşadığın şey klasik thundering herd: TTL bitince tek bir kullanıcı değil, binlerce istek aynı milisaniyede cache miss alıp aynı sorguyu PostgreSQL’e atıyor. Tek bir sorgu yeterken yüzlercesi koşuyor, bağlantı havuzu doluyor ve DB diz çöküyor. Önbelleğin tazeliğini kimin ittiği sorusunu edge cache ve invalidation kaydında ayrıca tartışmıştım; buradaki mesele o tazelemenin kaç kez koştuğu.
Neden
-
Önbellek expire ânında amacının tersini yapar. Görevi DB’yi korumakken, tüm yükü tek saniyeye sıkıştırır.
-
Sabit TTL senkronizasyon üretir. Tüm anahtarlara aynı 10 dakikayı verirseniz hepsi birlikte düşer; kıyameti beraber koparırlar.
-
Kullanıcıyı recompute’un arkasında bekletmek gereksiz. Elinizde bir saniye öncesine ait doğru bir değer varken onu sunmamak için bir sebep yok.
Ne yapmalı
-
Tek seferlik mutex (single-flight) lock kur. Miss anında ilk istek Redis’te kısa bir kilit alır (
SET NX PXile, ms cinsinden TTL’li); kilidi alan recompute eder ve cache’i doldurur. Böylece Postgres’e tek sorgu gider. Kilide her zaman TTL koy ki recompute eden süreç ölse bile kilit kalıcı kilitlenmesin. -
TTL’lere jitter ekle. TTL’yi
10dk ± rastgele birkaç dakikayaparsan anahtarlar farklı anlarda düşer, basınç doğal olarak yayılır. Tek satırlık değişiklik, büyük kazanç. -
Stale-while-revalidate ile kullanıcıyı bekletme. Anahtar expire olunca eldeki eski değeri sunmaya devam et, yenilemeyi arka planda yap. Bu, lock yaklaşımının “bekleyenler” maliyetini de sıfıra indirir.
-
Recompute gerçekten pahalıysa XFetch’e geç. Probabilistic early expiration ile her okuyucu, TTL bitimine yaklaştıkça recompute maliyetiyle orantılı bir olasılıkla erken yenilemeye karar verir; herd hiç oluşmaz. Daha zariftir ama uygulaması ve test etmesi daha incedir.
Sonuç: Ben olsam çoğu durumda single-flight lock + TTL jitter ile başlardım — birlikte vakaların büyük çoğunluğunu kapatır, operasyonu basittir, anlaması kolaydır. XFetch’i recompute gerçekten pahalı ve trafik gerçekten devasaysa devreye al. Ve hangisini seçersen seç, stale-while-revalidate’i ekle: kullanıcıyı bir DB sorgusunun arkasında asla bekletme.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.