Çok Katmanlı Önbellek Mimarisi: CDN'den Veritabanına

Önbellek neden mimari bir karardır, ayar değil?

Yüksek trafikli bir sistemde önbellek, sona eklenen bir hızlandırıcı değil; hangi verinin nerede, ne kadar süre, hangi tutarlılık sözüyle yaşayacağını belirleyen bir mimari katmandır. Yanlış kurulan önbellek iki şekilde vurur: bayat veriyle iş hatası, ya da topluca süresi dolan anahtarlarla veritabanına inen izdiham (cache stampede). Bu yazı katmanları, desenleri ve savunmaları tek haritada toplar.

Katman haritası: hangi veri nerede yaşar?

İlke basittir: veri kullanıcıya ne kadar yakın katmanda karşılanırsa sistem o kadar ucuz ölçeklenir. CDN'de emilen bir istek uygulamaya, yerelde emilen Redis'e, Redis'te emilen veritabanına hiç inmez — kapasite planı bu emilim oranları üzerine kurulur.

Erişim desenleri: cache-aside ve akrabaları

En yaygın desen cache-aside'dır: uygulama önce önbelleğe bakar, yoksa kaynaktan okur ve önbelleğe yazar — kontrol uygulamadadır, esnektir; bedeli ilk isteğin (cache miss) maliyeti ve doldurma yarışlarıdır. Read-through/write-through, okuma-yazmayı önbellek katmanının arkasına gizler; tutarlılık sözü netleşir, bağımlılık artar. Write-behind yazmaları tamponlayıp toplu iletir — yüksek yazma hızı satın alır, güç kaybında veri riski ve sıralama karmaşıklığı öder. Kurumsal pratikte varsayılan cache-aside + olay tabanlı geçersiz kılmadır; diğerleri ölçülmüş ihtiyaçla seçilir.

Geçersiz kılma: en zor problem, üç işleyen strateji

Birincisi TTL: her anahtarın ömrü vardır; basit ve dayanıklıdır, bedeli TTL penceresi kadar bayatlıktır. İkincisi olay tabanlı geçersiz kılma: veri değiştiğinde yayınlanan olay ilgili anahtarları siler — tazelik kazandırır, 'hangi değişiklik hangi anahtarları etkiler' haritasını ister ve olay kaçarsa TTL emniyet ağı olarak yine gerekir. Üçüncüsü sürümlü anahtar: içerik değişince anahtar da değişir (ör. fiyat listesi v42); eski anahtar silinmez, ölür — CDN'de purge yerine sürümlü URL bu desenin ta kendisidir. Pratik reçete: TTL her zaman + kritik veride olay tabanlı silme + değişmez içerikte sürümlü anahtar.

Cache stampede: izdiham savunması

Popüler bir anahtarın süresi dolduğunda yüzlerce eşzamanlı istek aynı anda kaynağa iner — buna stampede (dogpile/thundering herd) denir ve kampanya günü veritabanı çökmelerinin klasik nedenidir. Savunma katmanlıdır: tekil doldurma kilidi (aynı anahtar için kaynağa yalnız bir istek gider, diğerleri kısa süre bekler veya bayat değeri sunar); TTL jitter (ömürlere rastgele sapma eklenir ki anahtarlar topluca ölmesin); erken yenileme (ömrün sonuna yaklaşan sıcak anahtar, arka planda tazelenir); ve negatif önbellek ('bulunamadı' cevabı da kısa TTL ile saklanır ki olmayan kayıt sorguları kaynağı dövmesin). Bu dört mekanizma, yüksek trafikli önbelleğin standart donanımıdır.

İsabet oranı bir bütçedir

Önbellek, izlenmeyen yerde çürür: isabet oranı (hit ratio), tahliye (eviction) sayısı ve anahtar başına bellek panoda olmalıdır. Düşen isabet oranının üç klasik nedeni: anahtar tasarımında gereksiz çeşitlilik (aynı verinin farklı anahtarlarla saklanması), TTL'in iş ihtiyacından kısa olması ve belleğin küçük kalıp tahliye fırtınası üretmesi. Karar kuralı: her önbellek bölgesinin hedef isabet oranı yazılıdır; altına düşüş, alarm ve kök neden analizidir.

İş etkisi: en ucuz kapasite, hiç gelmeyen istektir

Önbellek yatırımının getirisi doğrudan altyapı faturasında okunur: CDN ve Redis'te emilen trafik, veritabanı ve uygulama katmanının küçük kalması demektir; p95 gecikmenin düşmesi dönüşüme yansır. Kampanya senaryolarında fark dramatikleşir — doğru katmanlanmış önbellek, zirve trafiğin büyük bölümünü kaynağa hiç indirmeden karşılar. 'Şu kadar eşzamanlı kullanıcıyı taşır mısınız?' sorusunun maliyet-verimli cevabı, makine değil emilim oranıdır.

Sık sorulan sorular

Yerel önbellek ile Redis birlikte mi kullanılmalı?

Sıcak ve küçük veri için evet (iki seviyeli önbellek): yerel katman mikrosaniye erişim verir, Redis paylaşım ve geçersiz kılma sağlar. Yerel kopyaların kısa TTL'i, düğümler arası tutarsızlık penceresini sınırlar.

Her şeyi önbelleğe almak neden yanlış?

Az okunan veri isabet üretmez, bellek yer ve tahliye baskısı yaratır; kişiye özel veriler ise yanlış anahtarlamayla sızıntı riski taşır. Önbellek, ölçülen sıcak veriye kurulur.

Önbellekte kişisel veri saklanabilir mi?

Gerekliyse; kullanıcı bazlı anahtarlama, şifreleme/kısıtlı erişim ve KVKK saklama sürelerine uyumlu TTL ile. Ortak anahtar altında kişisel veri saklamak en klasik sızıntı hatasıdır.

Stampede koruması framework'te hazır mı?

Caffeine'in tekil yükleme (loading cache) davranışı süreç içinde bunu verir; dağıtık katmanda kilit/erken yenileme kurgusu uygulama sorumluluğundadır ve kütüphane desteğiyle kurulur.

Önbellek mimarisi kontrol listesi

1. Katman haritası çıkarıldı: hangi veri CDN/yerel/Redis'te

2. Varsayılan desen cache-aside; istisnalar gerekçeli

3. TTL her anahtarda; kritik veride olay tabanlı geçersiz kılma

4. TTL jitter ve tekil doldurma kilidi aktif

5. Negatif önbellek ve erken yenileme sıcak anahtarlarda kurulu

6. İsabet/tahliye panoları ve hedef oranlar tanımlı

7. Kişisel veri içeren anahtarlar envanterde; TTL'ler KVKK ile hizalı

SSH Yazılım, yüksek trafikli sistemlerde önbellek mimarisi tasarımı ve stampede dayanıklılığı kurulumunu uçtan uca yürütür. Emilim oranınızı birlikte yükseltelim.