Önbellek Bileşeni

Ö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

Konfigürasyon Cache

• API Proxy konfigürasyonları
• Policy tanımları
• Routing bilgileri
• Metadata bilgileri

Token Cache

• OAuth2/JWT token'ları
• Token validation sonuçları
• User session bilgileri

Response Cache

• API response'ları
• Cache key bazlı saklama
• TTL (Time To Live) yönetimi
• Local veya distributed olarak yapılandırılabilir

ipucu

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

bilgi

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 edilir

Cache Key: URL + Header değerleri

Custom Key

Özel cache key oluşturma

Kullanıcı tanımlı cache key stratejileri kullanılabilir.

Cache TTL (Time To Live)

Sabit TTL

• Belirli bir süre için cache'de tutma
• Örnek: 5 dakika, 1 saat

Dinamik TTL

• Response header'larına göre TTL
• Cache-Control header'ı
• Expires header'ı

Conditional TTL

• 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