İçeriğe geç
Muhammet Şafak
en
Soran: Cem Cevaplandı:

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

  1. Ö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.

  2. Sabit TTL senkronizasyon üretir. Tüm anahtarlara aynı 10 dakikayı verirseniz hepsi birlikte düşer; kıyameti beraber koparırlar.

  3. 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ı

  1. Tek seferlik mutex (single-flight) lock kur. Miss anında ilk istek Redis’te kısa bir kilit alır (SET NX PX ile, 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.

  2. TTL’lere jitter ekle. TTL’yi 10dk ± rastgele birkaç dakika yaparsan anahtarlar farklı anlarda düşer, basınç doğal olarak yayılır. Tek satırlık değişiklik, büyük kazanç.

  3. 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.

  4. 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.

Paylaş:

Yorumlar

Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.

Diğer Sorular

Tüm sorular

Sitede Ara

Yazı, proje ve sayfalarda arama yapmak için yazmaya başlayın.

Esc ile kapat Pagefind ile güçlendirildi