Request
İstek müşteri CDN hostname’ine gelir.
Nasıl Çalışır?
Bir isteğin yolunu karara dönüştürüyoruz.
HızlıCDN’de amaç isteği yalnızca bir proxy’den geçirmek değil; cache, origin ve hata koşullarında hangi yolun izleneceğini önceden tanımlı bir operasyon modeline bağlamak.
REQUEST LIFECYCLECACHE + ORIGIN
VisitorREQUEST
HızlıCDNDECISION
CacheHIT / MISS
HITResponse
MISSOrigin routing
PRIMARYOrigin A
SECONDARYOrigin B
TERTIARYOrigin C
Request lifecycle
İstekten operasyona, aynı model.
Request akışı, cache kararı ve origin davranışı birbirinden kopuk ayarlar değil. HızlıCDN bunları tek bir karar zincirinde ele alır.
Cache decision
Cache key ve tanımlı politika üzerinden HIT / MISS kararı verilir.
Origin routing
MISS durumunda tanımlı origin sırası devreye girer.
Response
Yanıt cache veya uygun origin kaynağından kullanıcıya döner.
Operation
Health, purge ve gerekli politika değişiklikleri yönetilir.
Bir isteğin karar izi
Aynı istek.
Koşula göre doğru karar.
HızlıCDN’in farkı yalnızca cache tutmak değil; isteğin hangi koşulda nereden yanıtlanacağını görünür ve yönetilebilir bir karar akışına dönüştürmek.
REQUEST TRACE / USER CONTROLLED
VisitorREQUEST
HızlıCDNROUTING
Cache decisionHIT
CACHE RESPONSEYanıt cache’ten
ORIGIN ROUTINGAlternatif kaynaklar
PRIMARYOrigin AHEALTHY
SECONDARYOrigin BALTERNATIVE
TERTIARYOrigin CALTERNATIVE
RESPONSE SOURCECACHE
Origin failover
Origin’ler zincir değil, alternatif kaynaklardır.
Primary, secondary ve tertiary origin’ler aynı isteğin zorunlu ardışık durakları değildir. Cache MISS sonrasında routing katmanı tanımlı origin sırasını ve hata koşullarını uygular.
Primary uygun yanıt vermezse alternatif origin denenebilir. Her proje için gerçek origin kaynakları ve sıra aktivasyon öncesi doğrulanır.
ORDERED ORIGIN ROUTINGEXAMPLE
HızlıCDN routerMISS PATH
01 / PRIMARYOrigin ATRY FIRST
02 / SECONDARYOrigin BALTERNATIVE
03 / TERTIARYOrigin CALTERNATIVE
Origin sırası ve davranışı proje yapılandırmasına göre tanımlanır.
Stale delivery
Origin problemi her zaman boş yanıt demek değil.
Uygun cached içerik mevcutsa ve tanımlı hata / timeout koşulları oluşursa stale içerik geçici yanıt olarak sunulabilir. Bu davranış koşulsuz bir başarı garantisi değildir.
01Cached içerik mevcut mu?Gerekli
02Origin hata / timeout koşulu oluştu mu?Koşula bağlı
03Uygunsa stale responseGeçici teslim
Scoped purge
Cache’i gereksiz yere tamamen boşaltmayın.
HızlıCDN’in doğrulanan purge modeli ihtiyaca göre URL, prefix veya hostname kapsamını hedefleyebilir. Böylece değişmeyen içerik gereksiz yere yeniden doldurulmaz.
Tek kaynağı temizle.
/images/product-42.webpBir yolu temizle.
/theme/assets/…Bir hostname kapsamını temizle.
cdn.magaza.comCache policy
Cache key davranışı açıkça tanımlanır.
Query string, TTL ve asset türü gibi kararlar varsayıma bırakılmaz. Mevcut HızlıCDN V2 uyumluluk yaklaşımında query davranışı açık bir policy olarak ele alınır ve gerçek mağaza geçiş öncesi incelenir.
POLICY EXAMPLENOT LIVE TELEMETRY
ImagesLONG TTL POLICYDefined
CSS / JSSTATIC TTL POLICYDefined
FontsSTATIC TTL POLICYDefined
QueryCACHE-KEY BEHAVIORDefined
5xxNO CACHEProtected
404 / 410NEGATIVE CACHEPolicy
Controlled activation
Önce doğrula. Sonra bağla.
Yeni yapı canlı trafiğe bağlanmadan önce hostname, SSL, origin erişimi, cache davranışı ve health kontrolleri doğrulanır. Geçiş planında rollback yolu korunur.
01Existing state
Mevcut çalışan yapı referans alınır.
02Validation
Yeni cache ve origin davranışı ayrı ortamda kontrol edilir.
03Activation
DNS / hostname değişikliği kontrollü biçimde uygulanır.
04Health
Aktivasyon sonrası servis ve origin yanıtları doğrulanır.
05Rollback
Beklenmeyen durumda önceki çalışan yola geri dönüş planı korunur.
Engineering validation
Cache motorunu aynı koşullarda karşılaştırdık.
İzole same-host warm-cache benchmark’ında 500 request, concurrency 20 ve sıfır hata ile legacy PHP-FPM delivery ve Nginx proxy_cache ölçüldü.
Bu test gerçek müşteri trafiği veya bütün sayfa performansı değildir; runtime katmanlarını karşılaştıran engineering benchmark’tır.p95 RESPONSE TIMEDüşük değer daha iyi
P95
RPS
SSS
Teknik akış hakkında kısa cevaplar.
Cache hit olduğunda origin’e istek gider mi?
Hayır. Uygun cache kaydı HIT olduğunda yanıt cache katmanından döner; origin routing devreye girmez.
Primary origin yanıt vermezse ne olur?
Tanımlı failover koşullarında sıradaki alternatif origin denenebilir. Origin sırası ve hata davranışı proje yapılandırmasına göre belirlenir.
Stale delivery her origin hatasında çalışır mı?
Hayır. Stale delivery yalnız uygun cached içerik mevcutsa ve tanımlı hata / timeout koşulları oluştuğunda kullanılabilir.
Cache temizleme hangi kapsamda yapılabilir?
Doğrulanan operasyon modeli URL, prefix ve hostname kapsamındaki purge işlemlerini destekler.
Query string’ler cache key’i etkiler mi?
HızlıCDN V2’nin mevcut uyumluluk yaklaşımında query davranışı açık bir policy olarak tanımlanır. Gerçek mağaza davranışı geçiş öncesi incelenir.
Geçişte geri dönüş planı var mı?
Evet. Aktivasyon öncesi mevcut yapı korunur ve kontrollü geçişte rollback adımı operasyon planının parçası olarak ele alınır.
Teknik ön inceleme
Mevcut request yolunuzu birlikte çıkaralım.
Site adresinizi paylaşın. Cache, origin ve asset davranışını inceleyip HızlıCDN için uygun karar modelini belirleyelim.