Çoğu e-pin satıcısı, sitesi yavaşladığında ilk iş olarak sunucu paketini büyütür. Daha fazla çekirdek, daha fazla RAM, belki bir NVMe geçişi. Fatura iki katına çıkar, sayfa açılış süresi ise yüzde on beş iyileşir. Sonra kampanya günü gelir; eşzamanlı üç yüz kişi aynı anda aynı ürün sayfasını yeniler ve site yine dizlerinin üstüne çöker. Suçlu olarak hosting firması ilan edilir, oysa sorun hiç orada değildir.
Gerçek şu: bir e-pin satış scriptinin yavaşlığı neredeyse her zaman tekrar eden veritabanı sorgularından doğar. Aynı kategori ağacı, aynı döviz kuru, aynı stok sayısı, aynı kampanya listesi; değişmediği halde saniyede onlarca kez yeniden hesaplanır. Redis bu döngüyü kıran katmandır ve doğru kurulduğunda sunucuyu büyütmeden kapasiteyi katlar. Ama yanlış kurulduğunda müşteriye tükenmiş stoğu satar. Aşağıda o ince çizgiyi anlatıyorum.
Sunucunu büyütmek neden işe yaramıyor, hiç düşündün mü?
Bir dijital ürün satış scriptinde her istek şu zinciri kurar: oturum aç, kullanıcıyı bul, menüyü kur, kategorileri çek, ürünü çek, stoğu say, bayi fiyatını hesapla, kur tablosunu oku, kampanyayı kontrol et, son yorumları getir. Bu on ayrı sorgudur ve bunların sekizi son beş dakikada bir milim değişmemiştir. Sunucuyu büyütmek bu sekiz sorguyu daha hızlı yapmanı sağlar; ortadan kaldırmanı sağlamaz. Donanım, mimari hatanın faturasını ödemekten başka bir şey yapmaz.
Önbellek katmanı mantığı tersini yapar: sorgu sayısını azaltır. Menü on dakika boyunca aynıysa onu on dakika boyunca bellekte tut. Kur beş dakikada bir güncelleniyorsa beş dakika boyunca bellekten servis et. Böylece yüz eşzamanlı istekte veritabanına giden sorgu sayısı bine değil ona düşer. Kapasite artışı donanımdan değil, yapılmayan işten gelir. Bu yüzden ciddi bir e-pin yazılımı tercihi yaparken "Redis destekli mi?" sorusu, "kaç çekirdek ister?" sorusundan daha kritiktir.
Hangi veri önbelleğe girer, hangisi asla girmez?
Burada herkes aynı hatayı yapıyor: "Redis hızlıysa her şeyi Redis'e atalım." Bu düşünce e-pin işinde felakete götürür, çünkü senin sattığın şey stoktan düşen tekil bir koddur. Eğer stok sayısını on dakika önbelleğe alırsan, tükenmiş bir ürünü on dakika boyunca satmaya devam edersin. Elinde ödemesi alınmış ama teslim edilemeyen siparişler ve iade talepleri kalır.
Doğru yaklaşım veriyi "değişim hızına" göre sınıflamaktır. Kategori ağacı, sayfa metinleri, sabit içerikler saatlerce durabilir. Döviz kuru dakikalarca durabilir. Kullanıcının cüzdan bakiyesi, stok adedi ve sipariş durumu ise asla uzun süre önbellekte tutulmaz; bunlar ya hiç önbelleğe alınmaz ya da bir-iki saniyelik mikro ömürle alınır. Aşağıdaki tablo bu ayrımı net biçimde gösteriyor.
| Veri türü | Önerilen ömür (TTL) | Geçersizleştirme tetiği | Yanlış yapılırsa sonuç |
|---|---|---|---|
| Kategori ve menü ağacı | 1-6 saat | Panelden kategori kaydı | Yeni kategori sitede görünmez |
| Ürün adı, açıklama, görsel | 30-60 dakika | Ürün güncelleme | Eski açıklama servis edilir |
| Fiyat ve bayi kademesi | 5-15 dakika | Fiyat kaydı, kur güncellemesi | Zararına satış riski |
| Döviz kuru | 5 dakika | Kur çekme görevi | Kâr marjında sapma |
| Stok adedi | 0-2 saniye | Her satış ve her yükleme | Teslim edilemeyen sipariş |
| Cüzdan bakiyesi | Önbelleğe alınmaz | - | Çift harcama, muhasebe açığı |
| Oturum verisi | Oturum ömrü | Çıkış işlemi | Oturum kaybı veya karışması |
Önbelleği temizlemeyi kim tetikliyor: saat mi, olay mı?
Sadece süreye dayalı önbellek tembel çözümdür. Panelden bir ürünün fiyatını değiştirdiğinde, o değişikliğin sitede görünmesi için on beş dakika beklemek kabul edilemez. Bunun yerine olay tabanlı geçersizleştirme kurulur: kayıt işlemi başarıyla tamamlandığında ilgili anahtarlar silinir, bir sonraki ziyaretçi taze veriyi yeniden üretir ve önbelleğe yazar.
Bunu sürdürülebilir kılmanın yolu anahtar isimlendirmesinde disiplindir. Anahtarları proje:alan:kimlik:sürüm biçiminde kur. Böylece tek bir ürünü değiştirdiğinde tüm önbelleği uçurmak zorunda kalmazsın; sadece o ürünün ve onu içeren liste sayfalarının anahtarlarını düşürürsün. Toptan temizlik, kampanya anında yüz kişinin aynı saniyede veritabanına saldırması anlamına gelir ki bu, önbelleğin çözdüğü sorunun ta kendisidir.
Bir ürün sayfası isteğinde zamanın dağılımı (önbellek öncesi)
- Tekrar eden veritabanı sorguları 45%
- Şablon ve fiyat hesaplama 25%
- Dış servis çağrıları (kur, tedarikçi) 20%
- Ağ ve diğer yük 10%
Redis çökerse siten de çöker mi? Asıl tehlikeli soru bu
Önbellek katmanı eklemenin gizli bedeli bağımlılıktır. Kodun "Redis'ten oku, yoksa veritabanından oku" yerine "Redis'ten oku" biçiminde yazılmışsa, Redis servisi yeniden başladığı anda sitenin tamamı hata sayfasına döner. Doğru mimaride önbellek her zaman isteğe bağlı bir hızlandırıcıdır, hiçbir zaman tek gerçek kaynak değildir. Bağlantı kurulamazsa sistem sessizce veritabanına döner, yavaşlar ama satmaya devam eder.
İkinci tehlike bellek taşmasıdır. Redis'e sınırsız anahtar yazarsan bellek dolar ve servis anahtar atmaya başlar. Bu yüzden azami bellek ve atma politikası baştan tanımlanmalıdır. Önbellek için en uygun politika en az kullanılanı atmaktır; oturumları aynı örnekte tutuyorsan oturumların atılmaması için ayrı veritabanı indeksi veya ayrı örnek kullanmak gerekir. Bunu ayırmayan kurulumlarda müşteriler sepetleri boşalınca "site beni attı" diye yazar.
Stok kilidi için Redis kullanmak akıllıca mı?
Evet, ama önbellek olarak değil; kilit mekanizması olarak. E-pin işinde en pahalı hata aynı kodu iki müşteriye satmaktır. İki istek aynı milisaniyede son kodu görürse ikisi de satın alma akışına girer. Redis'in atomik yazma komutları burada kısa ömürlü bir kilit kurmaya yarar: kodu ayıran istek kilidi alır, diğeri bekler veya reddedilir. Kilit süresi kısa tutulur ve işlem bitince mutlaka bırakılır.
Yine de nihai doğruluk veritabanı tarafında kalmalıdır. Kod tahsisi, veritabanında koşullu güncelleme ile yapılmalı; yani "durumu boşta olan tek satırı kilitle ve satıldı olarak işaretle" mantığı işlem içinde yürütülmelidir. Redis kilidi yarışmayı azaltır, veritabanı kısıtı ise yarışma yaşansa bile mükerrer satışı imkânsız kılar. Ciddi bir e-pin scriptinde bu iki katman birlikte bulunur; biri performans, diğeri bütünlük içindir.
Redis'i kurmadan önce en yavaş üç sayfanın sorgu sayısını ve süresini yaz bir yere. Açtıktan sonra aynı ölçümü tekrarla. İyileşme yüzde yirminin altındaysa sorun önbellekte değil, sorgu ve indeks tasarımındadır; orayı düzeltmeden önbellek sadece hatayı gizler.
Kurulumu doğru yaptığını nasıl anlarsın?
Önbellek katmanı "kurdum, çalışıyor" denip geçilecek bir iş değildir. İsabet oranını, bellek kullanımını ve atılan anahtar sayısını düzenli izlemen gerekir. İsabet oranı yüzde seksenin altındaysa ya TTL çok kısadır ya anahtar isimlendirmesi her istekte farklı anahtar üretiyordur. Aşağıdaki kontrol listesini kurulumdan sonraki ilk hafta boyunca elinde tut.
| Kontrol | Nasıl doğrulanır | Beklenen sonuç | Durum |
|---|---|---|---|
| Redis dışarıya kapalı | Dış IP'den bağlantı denemesi | Bağlantı reddedilir, sadece yerel erişim | Zorunlu |
| Şifre tanımlı | Yapılandırma dosyasında kimlik doğrulama satırı | Şifresiz bağlantı reddedilir | Zorunlu |
| Azami bellek ve atma politikası | Servis bilgi komutu çıktısı | Sınır tanımlı, politika en az kullanılanı atar | Zorunlu |
| Redis kapalıyken site ayakta | Servisi test ortamında durdur | Site yavaşlar ama hata vermez | Zorunlu |
| Stok önbelleği kısa ömürlü | Ürünü tüket, sayfayı yenile | Tükendi bilgisi saniyeler içinde yansır | Zorunlu |
| Panel kaydı önbelleği düşürüyor | Fiyat değiştir, sayfayı kontrol et | Yeni fiyat anında görünür | Önerilir |
| Oturum ve önbellek ayrılmış | Veritabanı indeksi veya örnek ayrımı | Bellek dolunca oturum kaybolmaz | Önerilir |
| İsabet oranı izleniyor | Haftalık istatistik kaydı | Yüzde 80 ve üzeri | Önerilir |
Bu kontrollerin tamamını kendi kodunda elle kurmak mümkündür, ama her satış sayfası, her bayi kademesi ve her kur güncellemesi için ayrı ayrı düşünmek zorundasın. Hazır bir altyapı kullanmanın anlamı tam olarak budur: önbellek anahtarları, geçersizleştirme tetikleri ve stok kilidi zaten birbirine bağlı gelir. Pinova'nın mimarisinde bu katmanların nasıl ayrıldığını özellikler bölümünde görebilir, kendi trafiğine uygun paketi fiyat tablosunda karşılaştırabilirsin.
Önbellek katmanını sıfırdan yazmak zorunda değilsin
Stok kilidi, olay tabanlı geçersizleştirme ve güvenli geri dönüş mantığı kurulu bir dijital ürün satış yazılımı ile işe hızlandırmış başla.
Küçük bir sitede Redis gerçekten gerekli mi?
Günlük ziyaretçin üç yüzün altındaysa acil değil. Ama kampanya, yayıncı iş birliği veya reklam trafiği alıyorsan yük ani gelir. Önbellek katmanını sakin bir dönemde kurmak, çöküş anında kurmaya çalışmaktan çok daha kolaydır.
Stok bilgisini önbelleğe hiç almasam olur mu?
Olur ve çoğu durumda en güvenli seçim budur. Stok sorgusu doğru indekslenmişse zaten pahalı değildir. Önbelleğe alacaksan ömrü bir-iki saniyeyi geçmesin ve her satıştan sonra mutlaka düşür.
Redis yerine dosya tabanlı önbellek kullanabilir miyim?
Tek sunucuda düşük trafikte iş görür. Ancak dosya kilitleri eşzamanlı yükte tıkanır ve birden fazla sunucuya geçtiğinde önbellek tutarsız kalır. Bellek tabanlı çözüm hem daha hızlı hem de ölçeklenebilir.
Önbellek yüzünden müşteri yanlış fiyat görür mü?
Fiyat önbelleğinin ömrünü uzun tutarsan ve kur güncellemesi önbelleği düşürmüyorsa evet. Bu yüzden fiyat anahtarları, kur çekme görevinin sonunda mutlaka geçersizleştirilmelidir.
Önbellek, iyi kurulduğunda görünmez bir katmandır: müşteri sadece sitenin hızlı olduğunu fark eder. Kötü kurulduğunda ise en pahalı hataları üretir, çünkü yanlış veriyi güvenle servis eder. Bu dengeyi kendi kodunda kurmaya çalışmak yerine hazır ve test edilmiş bir yapı üzerinde çalışmak istiyorsan, katmanların nasıl davrandığını canlı demo üzerinde kendi gözünle dene; ürün sayfasını yenilerken stok ve fiyatın nasıl anında güncellendiğine dikkat et.