“H\u0131zl\u0131 Kahve, H\u0131zl\u0131 Veri: \u00d6nbellek Bo\u015faltma Politikalar\u0131yla Performans\u0131 Art\u0131rma Yollar\u0131”<\/p>\n
Bir an d\u00fc\u015f\u00fcn\u00fcn, favori k\u00fc\u00e7\u00fck kafenize gidiyorsunuz. Mis gibi kahve kokusu, s\u0131cak bir atmosfer… Ama s\u0131ra bir t\u00fcrl\u00fc ilerlemiyor! Barista, her sipari\u015f i\u00e7in taze \u00e7ekirdekleri al\u0131yor, \u00f6\u011f\u00fct\u00fcyor, demleme yap\u0131yor. Bu durum, web sitelerinizin veya uygulamalar\u0131n\u0131z\u0131n “\u00f6nbellek bo\u015faltma” stratejilerini do\u011fru y\u00f6netmedi\u011finde kar\u015f\u0131la\u015ft\u0131\u011f\u0131 performans\u0131 yava\u015flatan duruma olduk\u00e7a benziyor. Peki, dijital d\u00fcnyada bu kahve kuyru\u011funu nas\u0131l k\u0131salt\u0131r\u0131z?<\/p>\n
\u00d6nbellek (cache), bilgisayar bilimlerinde ve yaz\u0131l\u0131m geli\u015ftirmede, s\u0131k\u00e7a eri\u015filen verileri daha h\u0131zl\u0131 bir \u015fekilde sunmak amac\u0131yla ge\u00e7ici olarak depolayan bir mekanizmad\u0131r. T\u0131pk\u0131 bir kafenin en \u00e7ok satan kahve \u00e7ekirdeklerini veya taze pi\u015fmi\u015f simitleri tezg\u00e2h\u0131n kolay ula\u015f\u0131l\u0131r bir yerine koymas\u0131 gibi, \u00f6nbellek de en s\u0131k kullan\u0131lan bilgileri ana belle\u011fe (RAM) veya do\u011frudan CPU’ya yak\u0131n bir yere yerle\u015ftirerek eri\u015fim s\u00fcrelerini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r. Bu sayede, ayn\u0131 veriye tekrar ihtiya\u00e7 duyuldu\u011funda, \u00e7ok daha yava\u015f olan ana veri deposuna (\u00f6rne\u011fin bir veritaban\u0131, uzak sunucu veya disk) gitmek yerine, h\u0131zl\u0131 \u00f6nbellekten al\u0131n\u0131r. Bu “\u00f6nbellek isabeti” (cache hit) durumu, uygulaman\u0131z\u0131n performans\u0131n\u0131 ve kullan\u0131c\u0131 deneyimini do\u011frudan iyile\u015ftirir.<\/p>\n
Dijital bir kafe d\u00fc\u015f\u00fcn\u00fcn; her kahve sipari\u015fi bir veri iste\u011fi olsun. E\u011fer her kahveyi s\u0131f\u0131rdan, \u00e7ekirde\u011fi depodan \u00e7\u0131kar\u0131p \u00f6\u011f\u00fcterek haz\u0131rlasayd\u0131k, m\u00fc\u015fteriler uzun kuyruklar olu\u015fturur ve beklemekten s\u0131k\u0131l\u0131rd\u0131. Ancak barista, en \u00e7ok sipari\u015f edilen kahve t\u00fcrlerinin \u00e7ekirdeklerini tezgah\u0131n alt\u0131na, s\u0131k\u00e7a istenen s\u00fct ve \u015furuplar\u0131 elinin alt\u0131na koyarsa, servis s\u00fcresi dramatik \u015fekilde k\u0131sal\u0131r. \u0130\u015fte \u00f6nbellek de tam olarak budur: S\u0131k kullan\u0131lan verileri “tezgah\u0131n alt\u0131na” yerle\u015ftirmek. Bu, sadece h\u0131z sa\u011flamakla kalmaz, ayn\u0131 zamanda ana veritaban\u0131 sunucusunun \u00fczerindeki y\u00fck\u00fc azalt\u0131r, a\u011f trafi\u011fini d\u00fc\u015f\u00fcr\u00fcr ve genel sistem kaynaklar\u0131n\u0131n daha verimli kullan\u0131lmas\u0131na olanak tan\u0131r. \u00d6zellikle y\u00fcksek trafikli web sitelerinde, e-ticaret platformlar\u0131nda veya mobil uygulamalarda, \u00f6nbellek kullan\u0131m\u0131 bir l\u00fcks de\u011fil, bir zorunluluktur. Kullan\u0131c\u0131lar an\u0131nda yan\u0131t bekler ve her saniyelik gecikme, potansiyel m\u00fc\u015fteri kayb\u0131na yol a\u00e7abilir. Bu nedenle, \u00f6nbelle\u011fin do\u011fru bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131 ve y\u00f6netilmesi, modern yaz\u0131l\u0131m mimarilerinin temel ta\u015flar\u0131ndan biridir. Ancak, \u00f6nbellek dedi\u011fimiz bu “tezgah alan\u0131” s\u0131n\u0131rl\u0131d\u0131r. Sonsuz kahve \u00e7ekirde\u011fini veya sonsuz veriyi orada tutamay\u0131z. \u0130\u015fte tam da bu noktada “\u00f6nbellek bo\u015faltma” (cache eviction) devreye girer. Tezg\u00e2h doldu\u011funda, hangi eski \u00fcr\u00fcn\u00fcn yerini yeniye b\u0131rakaca\u011f\u0131n\u0131za karar vermeniz gerekir. Bu karar\u0131 do\u011fru vermek, kafenizin veya uygulaman\u0131z\u0131n ba\u015far\u0131s\u0131n\u0131 do\u011frudan etkiler. Yanl\u0131\u015f kararlar, kritik verilerin gereksiz yere \u00f6nbellekten at\u0131lmas\u0131na ve performans d\u00fc\u015f\u00fc\u015flerine neden olabilir.<\/p>\n
\u00d6nbelle\u011fin faydalar\u0131 tart\u0131\u015f\u0131lamazken, s\u0131n\u0131rl\u0131 kaynaklarla ba\u015fa \u00e7\u0131kma ihtiyac\u0131 “\u00f6nbellek bo\u015faltma” konusunu kritik hale getirir. Dijital d\u00fcnyada, \u00f6nbellek boyutu genellikle bellekle (RAM) s\u0131n\u0131rl\u0131d\u0131r. Bu, bir kafenin tezgah\u0131ndaki alan\u0131n s\u0131n\u0131rl\u0131 olmas\u0131 gibidir; s\u0131n\u0131rl\u0131 bir alana sadece belirli say\u0131da \u00fcr\u00fcn yerle\u015ftirebilirsiniz. Zamanla, \u00f6nbelle\u011fe yeni veriler eklenirken eski verilerin veya daha az \u00f6nemli verilerin kald\u0131r\u0131lmas\u0131 gerekir. Hangi verinin at\u0131laca\u011f\u0131na karar vermek, uygulaman\u0131z\u0131n performans\u0131n\u0131 ve verimlili\u011fini derinden etkileyen karma\u015f\u0131k bir karard\u0131r. Yanl\u0131\u015f bir \u00f6nbellek bo\u015faltma stratejisi, s\u0131k\u00e7a ihtiya\u00e7 duyulan verilerin \u00f6nbellekten at\u0131lmas\u0131na (cache miss) ve bunun sonucunda yava\u015f performansa yol a\u00e7abilir.<\/p>\n
Kafenizdeki senaryoyu ele alal\u0131m: S\u0131n\u0131rl\u0131 bir te\u015fhir alan\u0131n\u0131z var ve buraya m\u00fc\u015fterilerin h\u0131zl\u0131ca alabilece\u011fi at\u0131\u015ft\u0131rmal\u0131klar koyuyorsunuz. Bu durumlar, dijital \u00f6nbellek y\u00f6netiminde de kar\u015f\u0131m\u0131za \u00e7\u0131kar: \u00d6nbellek bo\u015faltma stratejileri, i\u015fte bu zorlu karar\u0131 otomatikle\u015ftirmek i\u00e7in geli\u015ftirilmi\u015f algoritmalard\u0131r. Her algoritman\u0131n kendine g\u00f6re avantajlar\u0131 ve dezavantajlar\u0131 vard\u0131r ve uygulaman\u0131z\u0131n ihtiya\u00e7lar\u0131na en uygun olan\u0131 se\u00e7mek, kritik bir m\u00fchendislik karar\u0131d\u0131r. Yanl\u0131\u015f bir politika se\u00e7imi, sisteminizi yava\u015flatabilir, kaynak israf\u0131na yol a\u00e7abilir ve kullan\u0131c\u0131lar\u0131 mutsuz edebilir. \u00d6rne\u011fin, bir haber sitesi, en son haberlerin h\u0131zl\u0131ca eri\u015filebilir olmas\u0131n\u0131 isterken, bir ar\u015fiv sitesi eski ama hala de\u011ferli verileri korumay\u0131 tercih edebilir. Her senaryo, farkl\u0131 bir \u00f6nbellek bo\u015faltma yakla\u015f\u0131m\u0131 gerektirir.<\/p>\n \u00d6nbellek bo\u015faltma politikalar\u0131, s\u0131n\u0131rl\u0131 bellek alan\u0131nda hangi verinin saklanaca\u011f\u0131n\u0131 ve hangi verinin at\u0131laca\u011f\u0131n\u0131 belirleyen kurallar setidir. T\u0131pk\u0131 kafenizin sahibinin tezg\u00e2h d\u00fczenlemesi i\u00e7in farkl\u0131 stratejiler uygulamas\u0131 gibi, yaz\u0131l\u0131m geli\u015ftiricileri de farkl\u0131 algoritmalar kullan\u0131r. \u0130\u015fte en yayg\u0131n olanlar\u0131 ve kafe benzetmeleriyle a\u00e7\u0131klamalar\u0131:<\/p>\n FIFO, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, \u00f6nbelle\u011fe ilk giren eleman\u0131n, \u00f6nbellek doldu\u011funda ilk \u00e7\u0131kar\u0131lacak eleman olaca\u011f\u0131 prensibine dayan\u0131r. Bu, uygulanmas\u0131 en basit politikalardan biridir.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Barista, sabah ilk haz\u0131rlad\u0131\u011f\u0131 kekin bitmesine yak\u0131n yeni bir kek pi\u015firdi\u011finde, yeni keki tezgaha koymak i\u00e7in sabahki ilk keki atar. M\u00fc\u015fterilerin kekleri ne s\u0131kl\u0131kta veya ne zaman ald\u0131klar\u0131na bakmaz, sadece “ilk giren” kural\u0131na uyar. LRU, \u00f6nbellek doldu\u011funda, en son en az kullan\u0131lan (yani en uzun s\u00fcredir eri\u015filmeyen) eleman\u0131 \u00f6nbellekten \u00e7\u0131karan bir politikad\u0131r. Bu, genellikle FIFO’dan daha iyi performans g\u00f6sterir \u00e7\u00fcnk\u00fc “ge\u00e7mi\u015fte \u00e7ok kullan\u0131lan bir verinin gelecekte de kullan\u0131lma olas\u0131l\u0131\u011f\u0131 y\u00fcksektir” varsay\u0131m\u0131na dayan\u0131r.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Barista, tezg\u00e2h doldu\u011funda, m\u00fc\u015fterilerin en uzun s\u00fcredir hi\u00e7 dokunmad\u0131\u011f\u0131 (veya sat\u0131n almad\u0131\u011f\u0131) \u00fcr\u00fcn\u00fc atar. \u00d6rne\u011fin, bir saat \u00f6nce gelen bir kurabiye, en son m\u00fc\u015fteri taraf\u0131ndan be\u015f dakika \u00f6nce al\u0131nan \u00e7\u00f6re\u011fe g\u00f6re daha \u00f6nce at\u0131lmaya adayd\u0131r. <\/code><\/p>\n LFU politikas\u0131, \u00f6nbellek doldu\u011funda en az s\u0131kl\u0131kta kullan\u0131lan eleman\u0131 \u00e7\u0131kar\u0131r. Bu, bir eleman\u0131n kullan\u0131m s\u0131kl\u0131\u011f\u0131n\u0131 takip etmeyi gerektirir. LRU'dan farkl\u0131 olarak, bir elemana s\u00fcrekli eri\u015filmemesi, at\u0131laca\u011f\u0131 anlam\u0131na gelmez; \u00f6nemli olan toplam eri\u015fim say\u0131s\u0131d\u0131r.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Barista, tezg\u00e2htaki \u00fcr\u00fcnler aras\u0131nda, a\u00e7\u0131ld\u0131\u011f\u0131 g\u00fcnden beri en az say\u0131da sat\u0131lan \u00fcr\u00fcn\u00fc atar. Belki o kurabiye iki g\u00fcnd\u00fcr hi\u00e7 satmad\u0131 ama ge\u00e7en hafta 100 tane sat\u0131lm\u0131\u015ft\u0131, yeni gelen bir kek ise daha hi\u00e7 sat\u0131lmad\u0131ysa o kek at\u0131l\u0131r. TTL (Time-To-Live), her \u00f6nbellek eleman\u0131na belirli bir ya\u015fam s\u00fcresi atar. Bu s\u00fcre sona erdi\u011finde, eleman otomatik olarak \u00f6nbellekten kald\u0131r\u0131l\u0131r. Di\u011fer politikalar belle\u011fin dolmas\u0131na odaklan\u0131rken, TTL verinin tazeli\u011fine odaklan\u0131r.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Barista, her kahve partisi i\u00e7in bir \"son kullanma tarihi\" belirler. Filtre kahve bir saat i\u00e7inde sat\u0131lmazsa, tazeli\u011fini yitirdi\u011fi varsay\u0131larak d\u00f6k\u00fcl\u00fcr ve yerine taze demlenir. Pastalar \u00fc\u00e7 g\u00fcn i\u00e7inde sat\u0131lmazsa at\u0131l\u0131r. ARC, IBM taraf\u0131ndan geli\u015ftirilen, LRU ve LFU'nun avantajlar\u0131n\u0131 birle\u015ftirmeye \u00e7al\u0131\u015fan hibrit bir algoritmad\u0131r. \u0130ki LRU listesi ve adaptif bir b\u00f6l\u00fcmleme kullanarak hem s\u0131k eri\u015filen hem de yak\u0131n zamanda eri\u015filen \u00f6\u011feleri optimize etmeye \u00e7al\u0131\u015f\u0131r.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Bu, kafenizin hem \"son sat\u0131lanlar\" (LRU) listesini hem de \"en \u00e7ok satanlar\" (LFU) listesini tutmas\u0131 gibidir. Tezg\u00e2h doldu\u011funda, hangisinin daha iyi performans sa\u011flayaca\u011f\u0131n\u0131 dinamik olarak belirleyerek, iki listeden birinden \u00fcr\u00fcn atar. B\u00f6ylece hem yeni pop\u00fcler trendleri yakalar hem de s\u00fcrekli favori olan \u00fcr\u00fcnleri g\u00f6z ard\u0131 etmez. Hayali bir dijital haber sitesi olan \"H\u0131zl\u0131 Haberler\"i ele alal\u0131m. Bu site, anl\u0131k haber ak\u0131\u015flar\u0131, makaleler ve videolar yay\u0131nl\u0131yor. Ba\u015flang\u0131\u00e7ta basit bir FIFO \u00f6nbellek politikas\u0131 kullan\u0131yorlard\u0131, ancak site trafi\u011fi artt\u0131k\u00e7a ciddi performans sorunlar\u0131 ya\u015famaya ba\u015flad\u0131lar.<\/p>\n \u0130lk Sorunlar (FIFO ile):<\/strong> \u00c7\u00f6z\u00fcm Aray\u0131\u015f\u0131:<\/strong> 1. LRU Denemesi:<\/strong> FIFO yerine LRU kullanmaya karar verdiler. Pop\u00fcler haberler (s\u0131k eri\u015filenler) \u00f6nbellekte daha uzun s\u00fcre kalmaya ba\u015flad\u0131. 2. TTL Entegrasyonu:<\/strong> Haberlerin do\u011fas\u0131 gere\u011fi belirli bir \"\u00f6mr\u00fc\" oldu\u011funu fark ettiler. \u00d6rne\u011fin, 24 saatten eski bir haberin anasayfada yer almas\u0131 pek anlaml\u0131 de\u011fildi. LRU ile birlikte her habere bir TTL (Time-To-Live) s\u00fcresi eklediler. Anasayfa ve kategori sayfalar\u0131 i\u00e7in 10 dakika, detayl\u0131 makaleler i\u00e7in 30 dakika TTL belirlediler. 3. Hibrid Yakla\u015f\u0131m ve \u0130yile\u015ftirmeler:<\/strong> Baz\u0131 kritik haberlerin (\u00f6rne\u011fin, son dakika duyurular\u0131) yay\u0131nland\u0131ktan sonra belirli bir s\u00fcre boyunca asla \u00f6nbellekten at\u0131lmamas\u0131n\u0131 sa\u011flamak i\u00e7in \"pinleme\" (pinning) mekanizmas\u0131 eklediler. Ayr\u0131ca, makalelerin kategorilerine g\u00f6re farkl\u0131 LRU ve TTL de\u011ferleri uygulamay\u0131 d\u00fc\u015f\u00fcnmeye ba\u015flad\u0131lar. \u00d6rne\u011fin, spor haberleri daha s\u0131k g\u00fcncellenirken, tarih makaleleri daha uzun s\u00fcre \u00f6nbellekte kalabilirdi.<\/p>\n Kafeye D\u00f6n\u00fc\u015f:<\/strong> <\/code><\/p>\n Tek bir kafenin \u00f6nbellek y\u00f6netimini \u00f6\u011frenmek harika, ancak ya kafenizi franchise yap\u0131p birden fazla \u015fube a\u00e7arsan\u0131z? Ya da men\u00fcn\u00fcz s\u00fcrekli de\u011fi\u015fen, dinamik bir yap\u0131ya b\u00fcr\u00fcn\u00fcrse? \u0130\u015fte burada ileri d\u00fczey \u00f6nbellek y\u00f6netimi devreye girer.<\/p>\n B\u00fcy\u00fck \u00f6l\u00e7ekli uygulamalarda veya mikro hizmet mimarilerinde tek bir sunucu \u00fczerindeki \u00f6nbellek yeterli olmaz. Birden fazla sunucunun (veya kafe \u015fubesinin) ayn\u0131 \u00f6nbelle\u011fe eri\u015fmesi ve g\u00fcncel kalmas\u0131 gerekir. Bu durumda \"da\u011f\u0131t\u0131k \u00f6nbellekler\" (distributed caches) kullan\u0131l\u0131r. Redis, Memcached gibi teknolojiler bu ihtiyac\u0131 kar\u015f\u0131lar.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Diyelim ki be\u015f \u015fubesi olan bir kafe zinciriniz var. Bir \u015fubede \"haftan\u0131n kahvesi\" belirlendi\u011finde, t\u00fcm \u015fubelerin bu bilgiyi an\u0131nda almas\u0131 ve kendi tezg\u00e2hlar\u0131n\u0131 buna g\u00f6re g\u00fcncellemesi gerekir. Aksi takdirde, bir m\u00fc\u015fteri bir \u015fubede haftan\u0131n kahvesini bulurken, di\u011ferinde bulamayabilir. Da\u011f\u0131t\u0131k \u00f6nbellek, bu bilgiyi merkezi bir yerde tutarak t\u00fcm \u015fubelerin (uygulama sunucular\u0131n\u0131n) h\u0131zl\u0131ca eri\u015fmesini sa\u011flar ve tutarl\u0131l\u0131k sorunlar\u0131n\u0131 \u00f6nler.<\/p>\n Bir veri kayna\u011f\u0131nda (\u00f6rne\u011fin veritaban\u0131nda) de\u011fi\u015fiklik oldu\u011funda, bu verinin \u00f6nbellekteki kopyas\u0131n\u0131n \"bayat\" (eski) hale geldi\u011fi anlam\u0131na gelir. Bu bayat kopyan\u0131n silinmesi veya g\u00fcncellenmesi i\u015flemine \"\u00f6nbellek ge\u00e7ersiz k\u0131lma\" denir. Yanl\u0131\u015f ge\u00e7ersiz k\u0131lma stratejileri, kullan\u0131c\u0131lar\u0131n eski veri g\u00f6rmesine veya gereksiz yere \u00f6nbellek ka\u00e7\u0131rmalar\u0131na neden olabilir.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Barista, g\u00fcnl\u00fck spesiyal men\u00fcy\u00fc g\u00fcncellerse, eski men\u00fcn\u00fcn hemen tezg\u00e2htan ve panodan kald\u0131r\u0131lmas\u0131 gerekir. M\u00fc\u015fteri eski men\u00fcye bak\u0131p sipari\u015f verdi\u011finde \"\u00fczg\u00fcn\u00fcz, o art\u0131k yok\" yan\u0131t\u0131n\u0131 almak istemez. \u00d6nbelle\u011fin do\u011fru boyutland\u0131r\u0131lmas\u0131 kritiktir. \u00c7ok k\u00fc\u00e7\u00fck bir \u00f6nbellek, d\u00fc\u015f\u00fck isabet oran\u0131yla sonu\u00e7lan\u0131rken, \u00e7ok b\u00fcy\u00fck bir \u00f6nbellek gereksiz yere bellek t\u00fcketir ve maliyetleri art\u0131r\u0131r. \u00d6nbellek izleme (monitoring) ara\u00e7lar\u0131, \u00f6nbellek isabet oran\u0131, bellek kullan\u0131m\u0131, bo\u015faltma say\u0131lar\u0131 gibi metrikleri takip ederek optimizasyon f\u0131rsatlar\u0131 sunar.<\/p>\n Kafe \u00d6rne\u011fi:<\/strong> Kafenizin tezg\u00e2h\u0131 ne kadar b\u00fcy\u00fck olmal\u0131? E\u011fer \u00e7ok k\u00fc\u00e7\u00fckse, s\u0131k s\u0131k depoya gidip gelmek zorunda kal\u0131rs\u0131n\u0131z. \u00c7ok b\u00fcy\u00fckse, gereksiz yere yer kaplar ve belki de kullanamayaca\u011f\u0131n\u0131z alan\u0131 bo\u015fa harcars\u0131n\u0131z. Bir y\u00f6netici, hangi \u00fcr\u00fcnlerin ne s\u0131kl\u0131kta sat\u0131ld\u0131\u011f\u0131n\u0131, ne kadar yer kaplad\u0131\u011f\u0131n\u0131 ve tezg\u00e2h\u0131n ne kadar\u0131n\u0131n bo\u015f kald\u0131\u011f\u0131n\u0131 s\u00fcrekli olarak izlemelidir. Bu verilerle tezg\u00e2h boyutunu ve \u00fcr\u00fcn yerle\u015fimini optimize edebilir. Dijital d\u00fcnyada bu, APM (Application Performance Monitoring) ara\u00e7lar\u0131 veya \u00f6nbellek sunucular\u0131n\u0131n kendi izleme panelleri ile yap\u0131l\u0131r.<\/p>\n
\n* Durum 1: Alan Doldu.<\/strong> G\u00fcn i\u00e7inde yeni, pop\u00fcler bir kek tarifi denediniz ve hemen te\u015fhir etmek istiyorsunuz. Ancak tezg\u00e2hta yer yok. Ne yapacaks\u0131n\u0131z? En eski simidi mi atacaks\u0131n\u0131z? En az satan\u0131 m\u0131? Yoksa az \u00f6nce gelen m\u00fc\u015fterinin almad\u0131\u011f\u0131 keki mi?
\n* Durum 2: Bayatlama.<\/strong> Tezg\u00e2htaki baz\u0131 \u00fcr\u00fcnler zamanla tazeli\u011fini yitirir (\u00f6rne\u011fin, bir saat \u00f6nce demlenmi\u015f ama kimsenin almad\u0131\u011f\u0131 filtre kahve). Bu \u00fcr\u00fcnler hala yer kapl\u0131yor ve birinin yanl\u0131\u015fl\u0131kla almas\u0131 k\u00f6t\u00fc bir deneyim yaratabilir.
\n* Durum 3: De\u011fi\u015fen Pop\u00fclerlik.<\/strong> D\u00fcn \u00e7ok satan bir kurabiye bug\u00fcn hi\u00e7 satm\u0131yor olabilirken, yeni bir sandvi\u00e7 an\u0131nda pop\u00fclerlik kazanm\u0131\u015f olabilir. \u00d6nbelle\u011finizi (tezgah\u0131n\u0131z\u0131) bu de\u011fi\u015fen talebe g\u00f6re s\u00fcrekli g\u00fcncel tutman\u0131z gerekir.<\/p>\n
\n* Bellek S\u0131n\u0131r\u0131:<\/strong> Fiziksel bellek (RAM) veya disk alan\u0131 k\u0131s\u0131tl\u0131d\u0131r. T\u00fcm verileri \u00f6nbellekte tutmak imkans\u0131zd\u0131r.
\n* Veri De\u011fi\u015fikli\u011fi (Invalidasyon):<\/strong> Kaynak veritaban\u0131ndaki bir veri g\u00fcncellendi\u011finde, \u00f6nbellekteki eski kopyas\u0131n\u0131n ge\u00e7ersiz k\u0131l\u0131nmas\u0131 ve kald\u0131r\u0131lmas\u0131 gerekir. Aksi takdirde, kullan\u0131c\u0131lar bayat (eski) veri g\u00f6rmeye devam eder.
\n* Optimal Performans Hedefi:<\/strong> Amac\u0131m\u0131z, \u00f6nbellek isabet oran\u0131n\u0131 (cache hit ratio) en \u00fcst d\u00fczeye \u00e7\u0131karmakt\u0131r. Yani, her iste\u011fin m\u00fcmk\u00fcn oldu\u011funca \u00f6nbellekten kar\u015f\u0131lanmas\u0131. Yanl\u0131\u015f bo\u015faltma politikalar\u0131, isabet oran\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcr ve performans\u0131 olumsuz etkiler.<\/p>\nKafenizin Tezg\u00e2h\u0131n\u0131 Nas\u0131l D\u00fczenlersiniz? Temel \u00d6nbellek Bo\u015faltma Politikalar\u0131<\/h2>\n
FIFO (First-In, First-Out): \u00d6nce Giren, \u00d6nce \u00c7\u0131kar m\u0131?<\/h3>\n
\nAvantajlar\u0131:<\/strong>
\n* Uygulamas\u0131 \u00e7ok kolayd\u0131r. Bir kuyruk (queue) veri yap\u0131s\u0131 ile rahatl\u0131kla y\u00f6netilebilir.
\n* Karma\u015f\u0131kl\u0131\u011f\u0131 d\u00fc\u015f\u00fckt\u00fcr, bu da onu h\u0131zl\u0131 yapar.
\nDezavantajlar\u0131:<\/strong>
\n* S\u0131k\u00e7a kullan\u0131lan ancak eski olan veriler, yeni gelen veriler taraf\u0131ndan kolayca at\u0131labilir. Bu, bir “\u00f6nbellek isabeti” durumunda verinin tekrar ana kaynaktan y\u00fcklenmesine yol a\u00e7arak performans\u0131 d\u00fc\u015f\u00fcrebilir. Kafede “en pop\u00fcler kek” sabah yap\u0131lm\u0131\u015f olsa bile, yeni bir kek geldi\u011finde at\u0131labilir ve bu m\u00fc\u015fteri deneyimini olumsuz etkiler.<\/p>\nLRU (Least Recently Used): En Az Yak\u0131n Zamanda Kullan\u0131lan\u0131 Atmak Ak\u0131ll\u0131ca m\u0131?<\/h3>\n
\nAvantajlar\u0131:<\/strong>
\n* Genellikle y\u00fcksek bir \u00f6nbellek isabet oran\u0131 sa\u011flar.
\n* Pop\u00fcler verileri \u00f6nbellekte tutma e\u011filimindedir.
\nDezavantajlar\u0131:<\/strong>
\n* Her eri\u015fimde verilerin kullan\u0131m zaman\u0131n\u0131 takip etmek gerekti\u011finden, FIFO’dan daha karma\u015f\u0131kt\u0131r. Genellikle bir \u00e7ift ba\u011fl\u0131 liste (doubly linked list) ve bir hash map kombinasyonu ile uygulan\u0131r.
\n* S\u00fcrekli olarak k\u0131sa s\u00fcreli\u011fine s\u0131k\u00e7a eri\u015filen veriler, daha uzun vadede \u00f6nemli olabilecek verileri itebilir.<\/p>\n\nclass LRUCache:\n def __init__(self, capacity: int):\n self.cache = {}\n self.capacity = capacity\n self.order = [] # En az kullan\u0131lan\u0131 takip etmek i\u00e7in\n\n def get(self, key: int) -> int:\n if key not in self.cache:\n return -1\n # Kullan\u0131lan eleman\u0131 listenin sonuna ta\u015f\u0131\n self.order.remove(key)\n self.order.append(key)\n return self.cache[key]\n\n def put(self, key: int, value: int) -> None:\n if key in self.cache:\n self.order.remove(key)\n elif len(self.cache) >= self.capacity:\n # En az kullan\u0131lan\u0131 (listenin ba\u015f\u0131ndaki) \u00e7\u0131kar\n lru_key = self.order.pop(0)\n del self.cache[lru_key]\n \n self.cache[key] = value\n self.order.append(key)\n\n# \u00d6rnek Kullan\u0131m\ncache = LRUCache(2)\ncache.put(1, 1)\ncache.put(2, 2)\nprint(cache.get(1)) # 1 d\u00f6nd\u00fcr\u00fcr, key 1 \u015fimdi en son kullan\u0131lan\ncache.put(3, 3) # capacity 2 oldu\u011fu i\u00e7in key 2 at\u0131l\u0131r\nprint(cache.get(2)) # -1 d\u00f6nd\u00fcr\u00fcr (bulunamaz)\ncache.put(4, 4) # capacity 2 oldu\u011fu i\u00e7in key 1 at\u0131l\u0131r\nprint(cache.get(1)) # -1 d\u00f6nd\u00fcr\u00fcr\nprint(cache.get(3)) # 3 d\u00f6nd\u00fcr\u00fcr\nprint(cache.get(4)) # 4 d\u00f6nd\u00fcr\u00fcr\n\n<\/pre>\nLFU (Least Frequently Used): En Az S\u0131k Kullan\u0131lan\u0131 \u00c7\u0131karmak Do\u011fru Se\u00e7im mi?<\/h3>\n
\nAvantajlar\u0131:<\/strong>
\n* Ger\u00e7ekten pop\u00fcler olan (s\u0131k\u00e7a eri\u015filen) verileri \u00f6nbellekte tutar.
\n* K\u0131sa s\u00fcreli pop\u00fclerlik dalgalanmalar\u0131ndan daha az etkilenir.
\nDezavantajlar\u0131:<\/strong>
\n* Uygulamas\u0131 LRU'dan daha karma\u015f\u0131kt\u0131r, \u00e7\u00fcnk\u00fc her eleman\u0131n kullan\u0131m say\u0131s\u0131n\u0131 tutmak ve g\u00fcncellemek gerekir.
\n* Bir zamanlar \u00e7ok pop\u00fcler olan ancak art\u0131k kullan\u0131lmayan bir veri, y\u00fcksek kullan\u0131m say\u0131s\u0131 nedeniyle \u00f6nbellekte uzun s\u00fcre kalabilir ve yeni, potansiyel olarak pop\u00fcler verilere yer a\u00e7maz. Bu sorunu \u00e7\u00f6zmek i\u00e7in LFU genellikle bir \"eskime\" (aging) mekanizmas\u0131 ile birle\u015ftirilir.<\/p>\nTTL (Time-To-Live): \u00dcr\u00fcnlerimin Son Kullanma Tarihi Ne Olmal\u0131?<\/h3>\n
\nAvantajlar\u0131:<\/strong>
\n* Verinin g\u00fcncelli\u011fini garanti eder. Bayat veya eski veri sunma riskini azalt\u0131r.
\n* \u00d6zellikle s\u0131k g\u00fcncellenen veriler (haber ba\u015fl\u0131klar\u0131, hisse senedi fiyatlar\u0131) i\u00e7in idealdir.
\nDezavantajlar\u0131:<\/strong>
\n* Bellek alan\u0131 dolulu\u011funu do\u011frudan y\u00f6netmez. Yani, e\u011fer t\u00fcm verilerin TTL s\u00fcresi uzunsa ve yeni veri ak\u0131\u015f\u0131 y\u00fcksekse, \u00f6nbellek yine de dolabilir. Bu durumda genellikle ba\u015fka bir bo\u015faltma politikas\u0131yla (LRU veya FIFO gibi) birle\u015ftirilerek kullan\u0131l\u0131r.
\n* Do\u011fru TTL s\u00fcresini belirlemek zordur. \u00c7ok k\u0131sa bir TTL, s\u0131k \u00f6nbellek ka\u00e7\u0131rmalar\u0131na, \u00e7ok uzun bir TTL ise bayat verilere yol a\u00e7abilir.<\/p>\nAdaptive Replacement Cache (ARC): Hem LRU Hem LFU Olmak M\u00fcmk\u00fcn m\u00fc?<\/h3>\n
\nAvantajlar\u0131:<\/strong>
\n* LRU ve LFU'dan genellikle daha iyi performans g\u00f6sterir.
\n* De\u011fi\u015fen eri\u015fim desenlerine adapte olabilir.
\nDezavantajlar\u0131:<\/strong>
\n* Uygulamas\u0131 olduk\u00e7a karma\u015f\u0131kt\u0131r.
\n* Y\u00fcksek i\u015flemci ve bellek kullan\u0131m\u0131 gerektirebilir.<\/p>\nBir Vaka Analizi: Dijital Haber Sitesinin \u00d6nbellek Stratejisi<\/h2>\n
\n* Haber Kayb\u0131:<\/strong> Bir haber ilk yay\u0131nland\u0131\u011f\u0131nda \u00f6nbelle\u011fe al\u0131n\u0131yor, ancak \u00e7ok pop\u00fcler olsa bile yeni haberler geldik\u00e7e \u00f6nbellekten at\u0131l\u0131yordu. Bu da pop\u00fcler haberlerin tekrar veritaban\u0131ndan \u00e7ekilmesine neden oluyordu.
\n* Bayat Haberler:<\/strong> Baz\u0131 haberler \u00e7ok pop\u00fcler de\u011fildi ama \u00f6nbellekte uzun s\u00fcre kal\u0131yordu, bu da bellekte yer i\u015fgal ediyordu.<\/p>\n
\nH\u0131zl\u0131 Haberler ekibi, bu sorunlar\u0131 gidermek i\u00e7in farkl\u0131 \u00f6nbellek bo\u015faltma politikalar\u0131n\u0131 de\u011ferlendirmeye ba\u015flad\u0131.<\/p>\n
\n * Sonu\u00e7:<\/strong> \u00d6nbellek isabet oran\u0131 (cache hit ratio) %65'ten %80'e \u00e7\u0131kt\u0131. Genel sayfa y\u00fckleme s\u00fcreleri %20 azald\u0131. Bu b\u00fcy\u00fck bir geli\u015fmeydi. Ancak, baz\u0131 haberler yay\u0131nland\u0131ktan hemen sonra \u00e7ok pop\u00fcler olup k\u0131sa s\u00fcre i\u00e7inde pop\u00fclerli\u011fini yitirse bile, son eri\u015fim zaman\u0131 g\u00fcncellendi\u011fi i\u00e7in uzun s\u00fcre \u00f6nbellekte kalabiliyordu. Yeni ama potansiyel olarak daha \u00f6nemli haberlere yer kalm\u0131yordu.<\/p>\n
\n * Sonu\u00e7:<\/strong> Bu sayede hem en s\u0131k okunan haberler (LRU sayesinde) \u00f6nbellekte tutulurken, belirli bir ya\u015fa ula\u015fan haberler otomatik olarak \u00f6nbellekten at\u0131lmaya ba\u015fland\u0131. Bu, \u00f6nbelle\u011fin daha taze ve g\u00fcncel i\u00e7erikle dolu kalmas\u0131n\u0131 sa\u011flad\u0131. \u00d6nbellek isabet oran\u0131 %85'e \u00e7\u0131kt\u0131 ve sistem kaynaklar\u0131 daha verimli kullan\u0131ld\u0131.<\/p>\n
\nH\u0131zl\u0131 Haberler'in hikayesi, kafenizin sadece \"en son sat\u0131lan\" \u00fcr\u00fcnleri tutmakla kalmay\u0131p, ayn\u0131 zamanda \"bayatlayan\" \u00fcr\u00fcnleri de belirli aral\u0131klarla tezg\u00e2htan kald\u0131rmas\u0131 ve \"en \u00e7ok satanlar\u0131\" daha uzun s\u00fcre tutmas\u0131 gerekti\u011fi anlam\u0131na gelir. Belirli d\u00f6nemlerde \"\u00f6zel \u00fcr\u00fcnlerin\" (son dakika haberleri) asla tezg\u00e2htan kald\u0131r\u0131lmamas\u0131n\u0131 sa\u011flamak da bu hibrit stratejinin bir par\u00e7as\u0131d\u0131r. Do\u011fru \u00f6nbellek bo\u015faltma politikalar\u0131yla, H\u0131zl\u0131 Haberler hem okuyucular\u0131na daha h\u0131zl\u0131 ve g\u00fcncel bir deneyim sunabildi hem de sunucu maliyetlerini d\u00fc\u015f\u00fcrd\u00fc.<\/p>\n\n# Basit bir LRU ve TTL kombinasyonu \u00f6rne\u011fi\nimport time\nfrom collections import OrderedDict\n\nclass HybridCache:\n def __init__(self, capacity: int, default_ttl_seconds: int = 300):\n self.cache = OrderedDict()\n self.capacity = capacity\n self.default_ttl = default_ttl_seconds\n\n def get(self, key: str) -> str:\n if key not in self.cache:\n return None\n \n value, expiry_time = self.cache[key]\n if time.time() > expiry_time:\n del self.cache[key] # TTL doldu, at\n return None\n \n # LRU mekanizmas\u0131: Eri\u015fimde eleman\u0131 listenin sonuna ta\u015f\u0131\n self.cache.move_to_end(key)\n return value\n\n def put(self, key: str, value: str, ttl_seconds: int = None) -> None:\n if key in self.cache:\n del self.cache[key] # Var olan\u0131 g\u00fcncellemek i\u00e7in \u00e7\u0131kar\n\n if len(self.cache) >= self.capacity:\n # LRU mekanizmas\u0131: En eskiyi (listenin ba\u015f\u0131ndaki) \u00e7\u0131kar\n self.cache.popitem(last=False) \n \n expiry_time = time.time() + (ttl_seconds if ttl_seconds is not None else self.default_ttl)\n self.cache[key] = (value, expiry_time)\n\n# \u00d6rnek Kullan\u0131m:\nhaber_cache = HybridCache(capacity=3, default_ttl_seconds=10) # 10 saniye TTL\n\nhaber_cache.put(\"haber1\", \"Uzayda Yeni Ke\u015fif\", ttl_seconds=5)\nhaber_cache.put(\"haber2\", \"Ekonomi Haberleri\")\nhaber_cache.put(\"haber3\", \"Spor Geli\u015fmeleri\")\n\nprint(f\"Haber 1: {haber_cache.get('haber1')}\") # Uzayda Yeni Ke\u015fif\n\n# Bir s\u00fcre bekleyelim\ntime.sleep(6) \n\nprint(f\"Haber 1 (TTL doldu): {haber_cache.get('haber1')}\") # None d\u00f6ner\n\nhaber_cache.put(\"haber4\", \"Son Dakika\") # Haber 2 veya Haber 3'ten biri at\u0131lacak (LRU'ya g\u00f6re)\n # Hangi haberin en ba\u015fta oldu\u011funa ba\u011fl\u0131d\u0131r\n # \u00d6rn: Haber 2 put edildi, sonra haber 3, sonra haber 1 get edildi.\n # Current order: haber2, haber3, haber1.\n # haber1 at\u0131ld\u0131. current order: haber2, haber3.\n # haber4 geldi. haber2 at\u0131ld\u0131. current order: haber3, haber4.\nprint(f\"Haber 2: {haber_cache.get('haber2')}\") # None d\u00f6ner (muhtemelen at\u0131ld\u0131)\nprint(f\"Haber 3: {haber_cache.get('haber3')}\") # Spor Geli\u015fmeleri\nprint(f\"Haber 4: {haber_cache.get('haber4')}\") # Son Dakika\n<\/pre>\n\u0130leri D\u00fczey \u00d6nbellek Y\u00f6netimi: Kafenizi Franchise Yapmaya Haz\u0131rlamak<\/h2>\n
Da\u011f\u0131t\u0131k \u00d6nbellekler: \u015eubeler Aras\u0131 Bilgi Payla\u015f\u0131m\u0131<\/h3>\n
\u00d6nbellek Ge\u00e7ersiz K\u0131lma (Cache Invalidation): Bayat \u00dcr\u00fcnleri H\u0131zl\u0131ca Kald\u0131rma<\/h3>\n
\nStratejiler:<\/strong>
\n* Write-through:<\/strong> Veri hem ana depoya hem de \u00f6nbelle\u011fe ayn\u0131 anda yaz\u0131l\u0131r. Basit ama performans\u0131 yava\u015flatabilir.
\n* Write-back:<\/strong> Veri \u00f6nce \u00f6nbelle\u011fe yaz\u0131l\u0131r, ard\u0131ndan belirli bir gecikmeyle veya toplu olarak ana depoya yaz\u0131l\u0131r. Daha h\u0131zl\u0131d\u0131r ancak veri kayb\u0131 riski ta\u015f\u0131r (\u00f6nbellek \u00e7\u00f6kmesi durumunda).
\n* Cache-aside:<\/strong> Uygulama \u00f6nce \u00f6nbelle\u011fe bakar. Veri yoksa ana depodan al\u0131r, ard\u0131ndan \u00f6nbelle\u011fe yazar. Veri g\u00fcncellendi\u011finde, sadece ana depoyu g\u00fcnceller ve ilgili veriyi \u00f6nbellekten \"ge\u00e7ersiz k\u0131lar\". Bu, en yayg\u0131n ve esnek yakla\u015f\u0131md\u0131r.<\/p>\n\u00d6nbellek Boyutland\u0131rmas\u0131 ve \u0130zleme: En \u0130deal Tezg\u00e2h Boyutu Nedir?<\/h3>\n
\n\n