# Redis cache stampede'i (thundering herd) nasıl önlerim — mutex lock mı, XFetch mi?

> Çoğu durumda single-flight lock ve TTL jitter yeter; XFetch'i recompute gerçekten pahalıyken açın ve her iki hâlde stale-while-revalidate ekleyin.

- Soruldu: 2026-05-16
- Yanıtlandı: 2026-05-19
- Soran: Cem
- Etiketler: performans, redis, caching
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/redis-cache-stampede-mutex-lock-mu-xfetch-mi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**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?


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.

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 amacı DB'yi korumakken, expire ânı tam tersini yapıp tüm yükü tek saniyeye sıkıştırıyor.

1. **Tek seferlik mutex (single-flight) lock.** 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; diğerleri o sırada ya kısa süre stale veriyi sunar ya da bekleyip yeni değeri okur. Böylece Postgres'e tek sorgu gider, yüzlercesi değil. Kilide her zaman TTL koy ki recompute eden süreç ölse bile kilit kalıcı kilitlenmesin.
2. **Probabilistic early expiration (XFetch).** Her okuyucu, TTL bitimine yaklaştıkça, recompute maliyetiyle orantılı bir olasılıkla "ben erken yenileyeyim mi?" diye rastgele karar verir. Yenileme tek ana toplanmadan, herd hiç oluşmadan dağıtılır. Recompute pahalı ve trafik çok yüksekse en zarif çözüm budur.
3. **TTL'lere jitter ekle.** Tüm anahtarlara sabit 10 dk verirsen hepsi senkron expire olur — kıyameti birlikte koparırlar. 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ç.
4. **Stale-while-revalidate ile kullanıcıyı bekletme.** Anahtar expire olunca eldeki eski değeri sunmaya devam et, yenilemeyi arka planda yap. Kullanıcı asla recompute'u beklemez; lock alan süreç sessizce cache'i tazeler. Bu, lock yaklaşımının "bekleyenler" maliyetini de sıfıra indirir.

**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; daha zariftir ama uygulaması ve test etmesi daha incedir. Ve hangisini seçersen seç, stale-while-revalidate'i ekle: kullanıcıyı bir DB sorgusunun arkasında asla bekletme.

## İlgili Yazılar

- [Redis'te canlı leaderboard için neden Sorted Set kullanmalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/redis-veri-tipleri-leaderboard-icin-sorted-set/) — Sor Bakalım
- [İşlediğim satırları aynı anda güncellerken chunk yerine chunkById mı kullanmalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/isledigim-satirlari-ayni-anda-guncellerken-chunk-yerine-chunkbyid-mi-kullanmaliyim/) — Sor Bakalım
- [Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/sadece-pending-satirlari-taranan-bir-kuyruk-tablosunda-partial-index-kullanmali-miyim/) — Sor Bakalım