Ana içeriğe atla

​
Önbellek Bileşeni Kavramı

Performans Artışı

Yanıt süresini azaltır

Backend Yükü

Backend yükünü hafifletir

Yüksek Erişilebilirlik

Backend hatalarına karşı koruma

Maliyet Tasarrufu

Backend kaynak kullanımını azaltır

​
Önbellek Bileşeni Türleri

​
Local Cache

  • API Proxy konfigürasyonları
  • Policy tanımları
  • Routing bilgileri
  • Metadata bilgileri
  • OAuth2/JWT token’ları
  • Token validation sonuçları
  • User session bilgileri
  • API response’ları
  • Cache key bazlı saklama
  • TTL (Time To Live) yönetimi
  • Local veya distributed olarak yapılandırılabilir
Response cache local olarak yapılandırıldığında Hazelcast kullanılmaz. Distributed olarak yapılandırıldığında Hazelcast kullanılır ve tüm API Gateway instance’ları arasında paylaşılır.

​
Distributed Cache (Hazelcast)

Hazelcast

Distributed cache altyapısı
  • Multi-node support
  • High availability
  • Yönetim ve izleme Apinizer’da yapılabilir
  • Gateway pod’larından bağımsız namespace’lerde çalışabilir

Paylaşılan Durum

Throttling, quota gibi veriler distributed tutulur
  • Throttling verileri
  • Quota verileri
  • Paylaşılan durum bilgileri
  • Cross-namespace erişim desteği

Response Cache

Response cache hem local hem distributed olabilir
  • Local response cache: Hazelcast kullanılmaz
  • Distributed response cache: Hazelcast kullanılır

Cache Invalidation

Otomatik ve event-based invalidation
  • Otomatik invalidation
  • Event-based invalidation
  • Pattern-based invalidation
Hazelcast, Apinizer tarafından yönetilir ve izlenebilir. Distributed cache kullanıldığında, throttling ve quota gibi veriler tüm API Gateway instance’ları arasında paylaşılır.Namespace Bağımsızlığı:Cache Server pod’ları artık Gateway pod’larından farklı Kubernetes namespace’lerinde çalışabilir. Gateway pod’ları diğer namespace’lerdeki cache sunucularına Kubernetes service discovery kullanarak erişebilir (örn: http://cache-http-service.apinizer-cache.svc.cluster.local:8090). Bu, daha esnek bir altyapı yönetimi sağlar ve Gateway ve Cache iş yüklerini ayırmanıza olanak tanır. Cache Server yapılandırması için Dağıtık Cache sayfasına bakın.

​
Önbellek Stratejileri

Cache-Aside (Lazy Loading)

  1. Cache’de ara
  2. Bulunamazsa backend’den al
  3. Cache’e kaydet
  4. İstemciye döndür

Write-Through

  1. Backend’e yaz
  2. Cache’e yaz
  3. İstemciye döndür

Write-Back (Write-Behind)

  1. Cache’e yaz
  2. İstemciye döndür
  3. Asenkron olarak backend’e yaz

​
Önbellek Yapılandırması

​
Cache Key Stratejisi

URL Bazlı

URL path’i cache key olarak kullanılırÖrnek: GET /api/v1/products → Cache Key: /api/v1/products

Query Parametreli

URL ve query parametreleri cache key’e dahil edilirÖrnek: GET /api/v1/products?category=electronics → Cache Key: /api/v1/products?category=electronics

Header Bazlı

URL ve belirli header değerleri cache key’e dahil edilirCache Key: URL + Header değerleri

Custom Key

Özel cache key oluşturmaKullanıcı tanımlı cache key stratejileri kullanılabilir.

​
Cache TTL (Time To Live)

  • Belirli bir süre için cache’de tutma
  • Örnek: 5 dakika, 1 saat
  • Response header’larına göre TTL
  • Cache-Control header’ı
  • Expires header’ı
  • Koşullu TTL
  • Response status code’a göre
  • Content type’a göre

​
Önbellek Invalidation

TTL Expiry

  • Zaman aşımı ile otomatik silme

Manual Invalidation

  • Manuel cache temizleme
  • API üzerinden invalidation

Event-Based

  • Event bazlı invalidation
  • Webhook ile invalidation

Pattern-Based

  • Pattern bazlı invalidation
  • Wildcard invalidation

​
Önbellek Kullanım Senaryoları

Response Caching

  1. İlk istek: Backend’den al, cache’e kaydet
  2. Sonraki istekler: Cache’den döndür
  3. TTL sonrası: Cache’i temizle, tekrar backend’den al

Token Caching

  1. Token doğrulama: Token cache’de var mı kontrol et
  2. Cache’de varsa: Doğrulama yapmadan döndür
  3. Cache’de yoksa: Identity Manager’dan doğrula, cache’e kaydet

Configuration Caching

  1. API Proxy konfigürasyonu: Management API’den al
  2. Local cache’e kaydet
  3. Konfigürasyon değişikliğinde: Cache’i invalidate et

Throttling ve Quota

  1. Throttling ve quota verileri distributed cache’de tutulur
  2. Tüm API Gateway instance’ları arasında paylaşılır (farklı namespace’lerde olsalar bile)
  3. Hazelcast üzerinden senkronize edilir
  4. Gateway pod’ları farklı namespace’lerdeki cache sunucularına Kubernetes service discovery ile erişir

​
Önbellek Best Practices

TTL Yönetimi

  • Uygun TTL değerleri seçin
  • Çok kısa TTL performansı düşürür
  • Çok uzun TTL stale data riski

Cache Key Design

  • Anlamlı cache key’ler
  • Collision’ları önleyin
  • Pattern-based invalidation

Memory Management

  • Cache size limitleri
  • Eviction policies
  • Memory monitoring

Error Handling

  • Cache hatalarında fallback
  • Backend’e yönlendirme
  • Error logging

​
Sonraki Adımlar

Veri Log Katmanı

Veri Log Katmanı mimarisini öğrenin

API Gateway

API Gateway bileşenini öğrenin