Skip to main content

> i̇ki_kademeli_önbellekleme_(l1_yerel_bellek_+_l2_redis_senkronizasyonu)

İki Kademeli Önbellekleme (L1 Yerel Bellek + L2 Redis Senkronizasyonu)

Yüksek verimli canlı mimarilerde İki Kademeli Önbellekleme (L1 Yerel Bellek + L2 Redis Senkronizasyonu) yapısını nasıl doğru kurar ve yönetirsiniz?

Stack: SOFTWARE ARCHITECTURE STACK →Staff/Principal (L6+)pattern

ÖZET VE TEKNİK CEVAP

İki Kademeli Önbellekleme, ultra hızlı L1 süreç içi bellek önbelleğini (Caffeine/GoCache) merkezi L2 dağıtık önbelleğiyle (Redis) birleştirir; veri değiştiğinde pod Redis'i günceller ve Redis Pub/Sub üzerinden geçersiz kılma sinyali yayarak tüm eş podların yerel L1 kayıtlarını anında silmesini sağlar.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Redis merkezi önbellekleme sunsa da, ağ üzerinden okuma yapmak 0.5-2 ms gecikme yaratır ve ağ bant genişliğini tüketir. Aşırı okunan sıcak anahtarlar (feature flag'ler, kiracı yetkileri) için Redis'i saniyede 100.000 kez sorgulamak Redis CPU'sunu tüketir. L1 süreç içi bellek önbelleği nanosaniye seviyesinde (0.0001 ms) erişim sağlar ancak tutarlılık sorununu doğurur: 50 bağımsız poddaki L1 önbelleği nasıl geçersiz kılınır?

2. Doğru Kullanım Senaryosu

İki Kademeli Önbellekleme, isteklerin önce yerel süreç belleğini (L1) kontrol ettiği, bulamazsa paylaşılan uzak Redis kümesini (L2) sorguladığı, yine bulamazsa veritabanına gidip podlar arası L1 geçersiz kılmalarını hafif mesajlaşmayla senkronize ettiği mimari bir hiyerarşidir.

3. Prodüksiyon Arıza Modları

20 podluk sisteme hiçbir geçersiz kılma mekanizması kurmadan L1 bellek önbelleği ekleyip 24 saat boyunca kullanıcılara tutarsız veri sunmak. Her yazmada hafif bir anahtar yerine tüm veri paketini Pub/Sub üzerinden yayarak ağda yayın amplifikasyonuna yol açmak. L1 bellek önbelleğine boyut sınırı koymayıp uygulamanın OutOfMemory ile çökmesine sebep olmak.

4. Teşhis ve Telemetri Sinyalleri

farklı podlardaki L1 bellekten bayat veri sunulması, yüksek frekanslı okuma döngülerinin Redis ağ bant genişliğini doyurması, eksik pub/sub yayını sebebiyle kalıcı ayrık-beyin (split-brain) durumu

5. Önleme ve Mimari Bariyerler

Redis Pub/Sub yayını yanında L1 için boyut sınırlı LRU (azami 10.000 kayıt) ve kısa TTL (30s) kullanın. Redis'in her istemcinin hangi anahtarları L1'de tuttuğunu otomatik izlediği Redis İstemci Taraflı Önbellekleme (RESP3 Tracking) özelliğini değerlendirin. Bellek tahsisini optimize etmek için L1 ve L2 önbellek isabet oranlarını Prometheus'ta ayrı ayrı ölçün.

6. Mimari Ödünleşimler (Trade-offs)

Redis kümesi maliyetlerini %80'den fazla düşürür, milisaniye altı API yanıt süreleri sunar ve yatay Kubernetes podları arasında bayat veri okunmamasını garanti eder.

Vaka İncelemesi (TinyCTO Örneği)

Koordineli bir İki Kademeli Önbellekte veri güncelleme yaşam döngüsü şöyle işler: 1. **Okuma Patikası:** İstek yerel L1'e bakar. Varsa -> 100 nanosaniyede döner. Yoksa -> L2 Redis'e bakar. Varsa -> L1'e yazar ve döner. Yoksa -> SQL veritabanından çeker, L2'ye kaydeder, L1'i doldurur ve döner. 2. **Yazma Patikası ve Geçersiz Kılma Yayını:** Kullanıcı profilini güncellediğinde Pod A PostgreSQL'e yazar ve L2 Redis anahtarını siler (`DEL user:123`). Ardından Pod A, Redis Pub/Sub üzerinden geçersiz kılma olayı yayınlar (`PUBLISH cache:invalidations user:123`). 3. **Eş Podların Yerel Temizliği:** Pod B, C ve D bu konuyu dinlemektedir. `user:123` mesajını aldıkları an yerel L1 belleklerindeki kaydı 1 milisaniye içinde silerler. *Kısa TTL Güvenlik Ağı:* Ağ dalgalanmasında kaybolabilecek Pub/Sub mesajlarına karşı tüm L1 kayıtlarına 30-60 saniyelik kısa bir azami TTL verilir.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

İki Kademeli Önbellekleme, yalnızca Redis sorgulamaya kıyasla hangi sorunu çözer?

Aşırı okunan sıcak anahtarları yerel süreç RAM'inden nanosaniyeler içinde sunarak ağ gecikmesini ve Redis CPU/bant genişliği doyumunu ortadan kaldırır.
Q2

Pod A bir kullanıcı kaydını güncellediğinde, diğer eş uygulama podları yerel L1 önbelleklerini geçersiz kılmaları gerektiğini nasıl öğrenir?

Pod A güncellenen anahtar ID'sini Redis Pub/Sub geçersiz kılma konusuna yayınlar; tüm eş podlar bu mesajı alıp ilgili anahtarı yerel belleklerinden siler.

İki Kademeli Önbellekleme (L1 Yerel Bellek + L2 Redis Senkronizasyonu) — Sıkça Sorulan Sorular

Uygulamanız L1 bellek önbelleğine sahip 50 Kubernetes podunda çalışıyor. Alice kullanıcısı şifresini Pod 1'de değiştiriyor. Pub/Sub geçersiz kılması olmadığı için Pod 2 on dakika boyunca eski şifreyi sunuyor. Bu arızaya ne denir?

Önbellek Tutarsızlığı (Cache Incoherence / Bayat Yerel Bellek Ayrışması). Önbellek Tutarsızlığı, düğümler arası geçersiz kılma mesajlaşması olmadığında çok düğümlü yerel önbelleklerin ana veri kaynağından kopmasıyla oluşur.

L1 bellek içi önbellekler neden HER ZAMAN sınırlı bir kapasiteye (örn. LRU ile azami 10.000 kayıt) ve bir azami TTL güvenlik ağına sahip olmalıdır?

Uygulama belleğinin OutOfMemory çöküşüne kadar kontrolsüz büyümesini önlemek ve bir Pub/Sub mesajı kaybolsa bile bayat verinin eninde sonunda silinmesini sağlamak için. Sınırlı LRU bellek sızıntılarını önler, yedek TTL ise ağ kopmasında geçersiz kılma yayını kaybolsa dahi nihai tutarlılığı garanti eder.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸İki Kademeli Önbellekleme, ultra hızlı L1 süreç içi bellek önbelleğini (Caffeine/GoCache) merkezi L2 dağıtık önbelleğiyle (Redis) birleştirir; veri değiştiğinde pod Redis'i günceller ve Redis Pub/Sub üzerinden geçersiz kılma sinyali yayarak tüm eş podların yerel L1 kayıtlarını anında silmesini sağlar.
  • ▸İki Kademeli Önbellekleme, isteklerin önce yerel süreç belleğini (L1) kontrol ettiği, bulamazsa paylaşılan uzak Redis kümesini (L2) sorguladığı, yine bulamazsa veritabanına gidip podlar arası L1 geçersiz kılmalarını hafif mesajlaşmayla senkronize ettiği mimari bir hiyerarşidir.

Yaygın Yanılgılar

  • ✗20 podluk sisteme hiçbir geçersiz kılma mekanizması kurmadan L1 bellek önbelleği ekleyip 24 saat boyunca kullanıcılara tutarsız veri sunmak.

Karar Kılavuzu & Önceliklendirme

Redis kümesi maliyetlerini %80'den fazla düşürür, milisaniye altı API yanıt süreleri sunar ve yatay Kubernetes podları arasında bayat veri okunmamasını garanti eder.

Doğrulanmış Kaynaklar & Referanslar

İlgili Kavramlar

https://tinycto.tv/topics/software-architecturehttps://tinycto.tv/incidentpedia