Modern web uygulamalar\u0131, \u00f6zellikle mikroservis mimarileri ve yo\u011fun veri ak\u0131\u015flar\u0131yla kar\u015f\u0131 kar\u015f\u0131ya kald\u0131\u011f\u0131nda, performans ve yan\u0131t s\u00fcresi kritik \u00f6neme sahiptir. Spring WebFlux’un reaktif do\u011fas\u0131 ve GraphQL’in esnek veri sorgulama yetenekleri, geli\u015ftiricilere g\u00fc\u00e7l\u00fc ara\u00e7lar sunarken, bu sistemlerin potansiyelini tam olarak kullanmak i\u00e7in etkili \u00f6nbellekleme stratejileri olmazsa olmazd\u0131r. Bu makale, WebFlux ve GraphQL tabanl\u0131 uygulamalarda y\u00fcksek performansl\u0131 yerel \u00f6nbellekleme \u00e7\u00f6z\u00fcm\u00fc Caffeine’in nas\u0131l entegre edilece\u011fini ve kullan\u0131laca\u011f\u0131n\u0131 detayl\u0131 bir \u015fekilde inceleyecektir.<\/p>\n
Spring WebFlux, non-blocking (engellemeyen) ve reaktif programlama paradigmas\u0131n\u0131 benimseyerek y\u00fcksek e\u015fzamanl\u0131l\u0131k ve \u00f6l\u00e7eklenebilirlik sunar. Ancak, reaktif ak\u0131\u015flar bile temel veri kaynaklar\u0131ndan (veritabanlar\u0131, harici API’ler) veri \u00e7ekme gecikmelerinden etkilenebilir. \u0130\u015fte bu noktada \u00f6nbellekleme devreye girer.<\/p>\n
Reaktif ak\u0131\u015flar, veri i\u015flemeyi e\u015fzamans\u0131z ve engellemeyen bir \u015fekilde y\u00f6netir. Ancak, bir veritaban\u0131 sorgusu veya uzak bir servise yap\u0131lan \u00e7a\u011fr\u0131 yine de belirli bir s\u00fcre alacakt\u0131r. Bu gecikmeler, \u00f6zellikle yo\u011fun y\u00fck alt\u0131nda birikerek genel sistem yan\u0131t s\u00fcresini olumsuz etkileyebilir. \u00d6nbellekleme, s\u0131k eri\u015filen verilerin bellekte tutulmas\u0131n\u0131 sa\u011flayarak bu gecikmeleri minimize eder ve reaktif ak\u0131\u015flar\u0131n daha h\u0131zl\u0131 tamamlanmas\u0131na olanak tan\u0131r.<\/p>\n
Spring Framework, \u00d6nbellekleme, uygulaman\u0131n performans\u0131n\u0131 art\u0131rman\u0131n yan\u0131 s\u0131ra, temel veri kaynaklar\u0131 \u00fczerindeki y\u00fck\u00fc de azalt\u0131r. Veritaban\u0131 ba\u011flant\u0131lar\u0131n\u0131n daha az kullan\u0131lmas\u0131, CPU ve a\u011f kaynaklar\u0131n\u0131n daha verimli kullan\u0131lmas\u0131 gibi avantajlar sunar. Bu, \u00f6zellikle maliyetli sorgular\u0131n veya s\u0131k eri\u015filen ancak nadiren de\u011fi\u015fen verilerin oldu\u011fu durumlarda b\u00fcy\u00fck bir fark yarat\u0131r.<\/p>\n GraphQL, istemcilerin tam olarak ihtiya\u00e7 duyduklar\u0131 veriyi tek bir sorgu ile alabilmelerini sa\u011flayarak REST API’lara k\u0131yasla daha esnek bir yakla\u015f\u0131m sunar. Ancak bu esneklik, \u00f6nbellekleme stratejilerini karma\u015f\u0131kla\u015ft\u0131rabilir.<\/p>\n GraphQL sorgular\u0131 olduk\u00e7a dinamiktir; istemciler farkl\u0131 alanlar\u0131 (fields) ve i\u00e7 i\u00e7e ge\u00e7mi\u015f ili\u015fkileri talep edebilirler. Bu durum, geleneksel REST API’lardaki gibi sabit URL’lere dayal\u0131 \u00f6nbellek anahtarlar\u0131 olu\u015fturmay\u0131 zorla\u015ft\u0131r\u0131r. Ayn\u0131 kaynak i\u00e7in farkl\u0131 sorgular farkl\u0131 sonu\u00e7lar d\u00f6nd\u00fcrebilir ve bu da \u00f6nbellek tutarl\u0131l\u0131\u011f\u0131 sorunlar\u0131na yol a\u00e7abilir. Etkili bir GraphQL \u00f6nbellekleme stratejisi, sorgu yap\u0131s\u0131n\u0131, de\u011fi\u015fkenleri ve hatta talep edilen alanlar\u0131 dikkate alan karma\u015f\u0131k anahtarlar olu\u015fturmay\u0131 gerektirebilir.<\/p>\n GraphQL’in i\u00e7 i\u00e7e ge\u00e7mi\u015f yap\u0131s\u0131, “N+1 problemi” olarak bilinen yayg\u0131n bir performans sorununa yol a\u00e7abilir. \u00d6rne\u011fin, bir liste kullan\u0131c\u0131 \u00e7ekildi\u011finde, her bir kullan\u0131c\u0131 i\u00e7in ayr\u0131 ayr\u0131 profil bilgisi \u00e7ekmek N+1 sorguya neden olur. Bu problemi \u00e7\u00f6zmek i\u00e7in GraphQL ekosisteminde “DataLoader” ad\u0131 verilen bir mekanizma kullan\u0131l\u0131r. DataLoader’lar, ayn\u0131 olay d\u00f6ng\u00fcs\u00fc i\u00e7inde yap\u0131lan birden fazla veri iste\u011fini toplu (batch) hale getirerek tek bir sorguda i\u015flemeyi sa\u011flar. DataLoader’lar performans\u0131 art\u0131rsa da, ayn\u0131 verinin tekrar tekrar y\u00fcklenmesini engellemek i\u00e7in \u00f6nbellekleme ile birlikte kullan\u0131lmas\u0131 idealdir.<\/p>\n GraphQL, bir kayna\u011f\u0131n yaln\u0131zca belirli alanlar\u0131n\u0131n g\u00fcncellenmesine olanak tan\u0131r. Bu durum, \u00f6nbellekteki bir nesnenin tamam\u0131n\u0131 ge\u00e7ersiz k\u0131lmak yerine, sadece de\u011fi\u015fen k\u0131s\u0131mlar\u0131n\u0131 g\u00fcncelleme ihtiyac\u0131n\u0131 do\u011furabilir. Ancak yerel \u00f6nbellekler genellikle nesnelerin tamam\u0131n\u0131 tuttu\u011fu i\u00e7in, k\u0131smi g\u00fcncellemeler \u00f6nbellek tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamay\u0131 zorla\u015ft\u0131r\u0131r. Bu nedenle, bir GraphQL mutasyonu (veri de\u011fi\u015fikli\u011fi) ger\u00e7ekle\u015fti\u011finde, ilgili \u00f6nbellek girdilerini dikkatlice ge\u00e7ersiz k\u0131lmak veya g\u00fcncellemek \u00f6nemlidir.<\/p>\n Caffeine, Java i\u00e7in geli\u015ftirilmi\u015f, y\u00fcksek performansl\u0131 ve modern bir yerel (in-memory) \u00f6nbellekleme k\u00fct\u00fcphanesidir. Google Guava Cache’in halefi olarak kabul edilir ve bir\u00e7ok geli\u015fmi\u015f \u00f6zelli\u011fe sahiptir.<\/p>\n Basit Caffeine’in Caffeine’i WebFlux ve GraphQL uygulamalar\u0131n\u0131za entegre etmek, Spring’in g\u00fc\u00e7l\u00fc \u00f6nbellek soyutlamas\u0131 sayesinde olduk\u00e7a basittir.<\/p>\n \u00d6ncelikle, projenize Caffeine ba\u011f\u0131ml\u0131l\u0131\u011f\u0131n\u0131 eklemeniz gerekir:<\/p>\n <\/code><\/p>\n Ard\u0131ndan, Spring Boot uygulaman\u0131zda \u00f6nbelleklemeyi etkinle\u015ftirmeniz ve Caffeine'i yap\u0131land\u0131rman\u0131z gerekir:<\/p>\n <\/code><\/p>\n Art\u0131k servis metodlar\u0131n\u0131zda <\/code><\/p>\n Bazen <\/code><\/p>\n GraphQL Java k\u00fct\u00fcphanesi ile <\/code><\/p>\n Bu \u00f6rnekte, Etkili bir \u00f6nbellekleme stratejisi olu\u015fturmak, uygulaman\u0131z\u0131n performans\u0131n\u0131 maksimize etmek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n \u00d6nbellekteki verilerin g\u00fcncel kalmas\u0131n\u0131 sa\u011flamak, \u00f6nbellek tutarl\u0131l\u0131\u011f\u0131 a\u00e7\u0131s\u0131ndan hayati \u00f6neme sahiptir. Caffeine, \u00d6nbelle\u011fin boyutu, uygulaman\u0131n bellek t\u00fcketimi \u00fczerinde do\u011frudan bir etkiye sahiptir. Farkl\u0131 veri t\u00fcrleri veya farkl\u0131 eri\u015fim desenleri olan veriler i\u00e7in ayr\u0131 \u00f6nbellekler kullanmak faydal\u0131 olabilir. \u00d6rne\u011fin, \"\u00fcr\u00fcnler\" i\u00e7in ayr\u0131 bir \u00f6nbellek, \"kullan\u0131c\u0131lar\" i\u00e7in ayr\u0131 bir \u00f6nbellek olu\u015fturabilirsiniz. Bu, her \u00f6nbelle\u011fin kendi TTL\/TTI ve boyut politikalar\u0131na sahip olmas\u0131n\u0131 sa\u011flar ve bir veri t\u00fcr\u00fcndeki de\u011fi\u015fikliklerin di\u011fer \u00f6nbellekleri etkilemesini engeller. Spring Cache Abstraction'da \u00d6nbelleklerin en b\u00fcy\u00fck zorluklar\u0131ndan biri, temel veri kayna\u011f\u0131ndaki bir de\u011fi\u015fiklik oldu\u011funda \u00f6nbellekteki verilerin g\u00fcncel kalmas\u0131n\u0131 sa\u011flamakt\u0131r. Buna \"\u00f6nbellek ge\u00e7ersiz k\u0131lma\" denir.<\/p>\n Veri taban\u0131nda veya harici bir serviste bir de\u011fi\u015fiklik (ekleme, g\u00fcncelleme, silme) oldu\u011funda, ilgili \u00f6nbellek girdilerini manuel olarak ge\u00e7ersiz k\u0131lmak gerekebilir. Spring'in <\/code><\/p>\n Programatik \u00f6nbelleklerde ise Daha karma\u015f\u0131k senaryolarda, alan tabanl\u0131 veya ili\u015fki tabanl\u0131 ge\u00e7ersiz k\u0131lma gerekebilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n profil resmi de\u011fi\u015fti\u011finde, o kullan\u0131c\u0131n\u0131n profilini g\u00f6steren t\u00fcm \u00f6nbellek girdilerini ge\u00e7ersiz k\u0131lmak isteyebilirsiniz. Bu t\u00fcr durumlar i\u00e7in, domain olaylar\u0131n\u0131 (domain events) dinleyen ve bu olaylara g\u00f6re \u00f6nbellekleri ge\u00e7ersiz k\u0131lan bir mekanizma kurmak faydal\u0131 olabilir. Spring'in uygulama olaylar\u0131 (Application Events) veya Reactor'\u0131n event bus yap\u0131lar\u0131 bu konuda yard\u0131mc\u0131 olabilir.<\/p>\n \u00d6nbelle\u011fin performans\u0131n\u0131 anlamak ve sorunlar\u0131 tespit etmek i\u00e7in izleme ve metrikler hayati \u00f6neme sahiptir. Caffeine, <\/code><\/p>\n Bu istatistiklere eri\u015ferek \u00f6nbelle\u011finizin ne kadar etkili \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6rebilirsiniz.<\/p>\n WebFlux ve GraphQL tabanl\u0131 uygulamalar, modern ve y\u00fcksek performansl\u0131 sistemler olu\u015fturmak i\u00e7in g\u00fc\u00e7l\u00fc bir kombinasyon sunar. Ancak, bu sistemlerin tam potansiyelini ortaya \u00e7\u0131karmak i\u00e7in etkili bir \u00f6nbellekleme stratejisi \u015fartt\u0131r. Caffeine, y\u00fcksek performansl\u0131, esnek ve Spring ile kolayca entegre edilebilen bir yerel \u00f6nbellek \u00e7\u00f6z\u00fcm\u00fc olarak bu ihtiyac\u0131 m\u00fckemmel bir \u015fekilde kar\u015f\u0131lar. Do\u011fru \u00f6nbellek stratejileri, uygun TTL\/TTI ayarlar\u0131, boyut y\u00f6netimi ve dikkatli ge\u00e7ersiz k\u0131lma mekanizmalar\u0131 ile WebFlux-GraphQL uygulamalar\u0131n\u0131z\u0131n yan\u0131t s\u00fcrelerini \u00f6nemli \u00f6l\u00e7\u00fcde iyile\u015ftirebilir, temel veri kaynaklar\u0131 \u00fczerindeki y\u00fck\u00fc azaltabilir ve genel kullan\u0131c\u0131 deneyimini art\u0131rabilirsiniz. Reaktif ak\u0131\u015flar\u0131n non-blocking do\u011fas\u0131 ile Caffeine'in asenkron yeteneklerinin birle\u015fimi, uygulaman\u0131z\u0131n \u00f6l\u00e7eklenebilirli\u011fini ve verimlili\u011fini yeni bir seviyeye ta\u015f\u0131yacakt\u0131r.<\/p>\n Caffeine, y\u00fcksek e\u015fzamanl\u0131l\u0131k ve d\u00fc\u015f\u00fck gecikme i\u00e7in tasarlanm\u0131\u015f, performans\u0131 optimize edilmi\u015f bir yerel \u00f6nbellek k\u00fct\u00fcphanesidir. WebFlux'un reaktif ve non-blocking do\u011fas\u0131yla m\u00fckemmel uyum sa\u011flar. \u00d6zellikle GraphQL'in esnek sorgu yap\u0131s\u0131 nedeniyle sabit URL'lere dayal\u0131 anahtarlar yetersiz kalabilir. En iyi yakla\u015f\u0131m, sorgunun benzersiz bir temsilini (\u00f6rn. sorgu dizesi, de\u011fi\u015fkenler ve talep edilen alanlar\u0131n hash'i) \u00f6nbellek anahtar\u0131 olarak kullanmakt\u0131r. DataLoader'lar genellikle nesne ID'lerine dayal\u0131 anahtarlar kullan\u0131r, bu da daha tutarl\u0131 bir \u00f6nbellekleme sa\u011flar.<\/p>\n Hay\u0131r, Caffeine bir yerel (in-memory) \u00f6nbellektir ve tek bir uygulama \u00f6rne\u011fi i\u00e7inde \u00e7al\u0131\u015f\u0131r. Da\u011f\u0131t\u0131k bir ortamda birden fazla uygulama \u00f6rne\u011finiz varsa, her \u00f6rnek kendi Caffeine \u00f6nbelle\u011fine sahip olacakt\u0131r. Uygulamalar aras\u0131nda veri tutarl\u0131l\u0131\u011f\u0131 sa\u011flamak i\u00e7in Redis, Hazelcast gibi da\u011f\u0131t\u0131k \u00f6nbellek \u00e7\u00f6z\u00fcmlerini kullanman\u0131z veya Caffeine ile birlikte bu \u00e7\u00f6z\u00fcmleri bir katman olarak kullanman\u0131z gerekir.<\/p>\n D\u00fc\u015f\u00fck bir isabet oran\u0131, \u00f6nbelle\u011finizin etkili \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Bunun birka\u00e7 nedeni olabilir:<\/p>\n Caffeine, @Cacheable<\/code>, @CachePut<\/code> ve @CacheEvict<\/code> gibi anotasyonlar arac\u0131l\u0131\u011f\u0131yla deklaratif \u00f6nbellekleme deste\u011fi sunar. WebFlux uygulamalar\u0131nda da bu anotasyonlar kullan\u0131labilir, ancak reaktif tipler (Mono<\/code> ve Flux<\/code>) ile \u00e7al\u0131\u015f\u0131rken baz\u0131 n\u00fcanslar ortaya \u00e7\u0131kar. Spring’in \u00f6nbellek soyutlamas\u0131, reaktif ak\u0131\u015flar\u0131 otomatik olarak \u00e7\u00f6zer ve sonu\u00e7lar\u0131 \u00f6nbelle\u011fe al\u0131r. Bu sayede, metodun her \u00e7a\u011fr\u0131l\u0131\u015f\u0131nda ayn\u0131 veri kayna\u011f\u0131na gitmek yerine, \u00f6nbellekteki veriler an\u0131nda d\u00f6nebilir.<\/p>\nPerformans ve Kaynak Verimlili\u011fi<\/h3>\n
GraphQL ve \u00d6nbellekleme Zorluklar\u0131<\/h2>\n
Esnek Sorgu Yap\u0131s\u0131 ve \u00d6nbellek Anahtarlar\u0131<\/h3>\n
N+1 Problemi ve Veri Y\u00fckleyiciler (DataLoaders)<\/h3>\n
K\u0131smi Veri G\u00fcncellemeleri<\/h3>\n
Caffeine: Y\u00fcksek Performansl\u0131 Yerel \u00d6nbellek \u00c7\u00f6z\u00fcm\u00fc<\/h2>\n
Caffeine’in Temel \u00d6zellikleri<\/h3>\n
\n
expireAfterAccess<\/code> (son eri\u015fimden sonra), expireAfterWrite<\/code> (son yazmadan sonra) ve expireAfter<\/code> (belirli bir s\u00fcre sonra) gibi esnek zaman tabanl\u0131 son kullanma se\u00e7enekleri sunar.<\/li>\nAsyncCache<\/code> aray\u00fcz\u00fc ile asenkron veri y\u00fckleme ve yenileme yetenekleri sa\u011flar, bu da reaktif uygulamalar i\u00e7in idealdir.<\/li>\nNeden Caffeine?<\/h3>\n
ConcurrentHashMap<\/code> kullanmak yerine Caffeine tercih etmenin bir\u00e7ok nedeni vard\u0131r:<\/p>\n\n
ConcurrentHashMap<\/code>‘ten \u00e7ok daha iyi performans g\u00f6sterir.<\/li>\nReaktif Ortamda Caffeine Kullan\u0131m\u0131<\/h3>\n
AsyncCache<\/code> aray\u00fcz\u00fc, reaktif uygulamalar i\u00e7in bi\u00e7ilmi\u015f kaftand\u0131r. Mono<\/code> veya Flux<\/code> d\u00f6nd\u00fcren metodlar\u0131n sonu\u00e7lar\u0131n\u0131 asenkron olarak \u00f6nbelle\u011fe alabilir ve d\u00f6nd\u00fcrebilir. Bu, \u00f6nbellek y\u00fckleme i\u015flemlerinin ana i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131 (thread) bloke etmeden ger\u00e7ekle\u015fmesini sa\u011flar, WebFlux’un non-blocking do\u011fas\u0131na m\u00fckemmel uyum sa\u011flar.<\/p>\nWebFlux-GraphQL Uygulamalar\u0131nda Caffeine Entegrasyonu<\/h2>\n
Spring Cache Abstraction ile Entegrasyon<\/h3>\n
\n\nimport com.github.benmanes.caffeine.cache.Caffeine;\nimport org.springframework.cache.CacheManager;\nimport org.springframework.cache.annotation.EnableCaching;\nimport org.springframework.cache.caffeine.CaffeineCacheManager;\nimport org.springframework.context.annotation.Bean;\nimport org.springframework.context.annotation.Configuration;\n\nimport java.util.concurrent.TimeUnit;\n\n@Configuration\n@EnableCaching\npublic class CacheConfig {\n\n @Bean\n public CacheManager cacheManager() {\n CaffeineCacheManager cacheManager = new CaffeineCacheManager();\n cacheManager.setCaffeine(Caffeine.newBuilder()\n .expireAfterWrite(10, TimeUnit.MINUTES) \/\/ 10 dakika sonra yaz\u0131ld\u0131ktan sonra son kullanma\n .maximumSize(1000)); \/\/ Maksimum 1000 \u00f6\u011fe\n return cacheManager;\n }\n}\n<\/pre>\n@Cacheable<\/code> anotasyonunu kullanabilirsiniz:<\/p>\n\nimport org.springframework.cache.annotation.Cacheable;\nimport org.springframework.stereotype.Service;\nimport reactor.core.publisher.Mono;\n\n@Service\npublic class ProductService {\n\n @Cacheable(value = \"products\", key = \"#id\")\n public MonoProgramatik \u00d6nbellek Y\u00f6netimi<\/h3>\n
@Cacheable<\/code> anotasyonu, GraphQL'in karma\u015f\u0131k sorgu yap\u0131s\u0131 veya \u00f6zel \u00f6nbellek anahtar\u0131 gereksinimleri nedeniyle yeterli olmayabilir. Bu durumlarda, Caffeine'in do\u011frudan API'sini kullanarak programatik olarak \u00f6nbelle\u011fi y\u00f6netebilirsiniz.<\/p>\n\nimport com.github.benmanes.caffeine.cache.AsyncCache;\nimport com.github.benmanes.caffeine.cache.Caffeine;\nimport org.springframework.stereotype.Component;\nimport reactor.core.publisher.Mono;\n\nimport java.time.Duration;\nimport java.util.concurrent.CompletableFuture;\nimport java.util.concurrent.TimeUnit;\n\n@Component\npublic class CustomGraphQLCache {\n\n private final AsyncCacheGraphQL DataFetcher'larda \u00d6nbellekleme<\/h3>\n
DataFetcher<\/code>'lar\u0131 uygularken, yukar\u0131daki programatik \u00f6nbellekleme yakla\u015f\u0131m\u0131n\u0131 kullanmak olduk\u00e7a yayg\u0131nd\u0131r.<\/p>\n\nimport graphql.schema.DataFetcher;\nimport graphql.schema.DataFetchingEnvironment;\nimport org.springframework.beans.factory.annotation.Autowired;\nimport org.springframework.stereotype.Component;\nimport reactor.core.publisher.Mono;\n\n@Component\npublic class ProductDataFetcher implements DataFetcherProductDataFetcher<\/code>, productId<\/code> arg\u00fcman\u0131na g\u00f6re \u00fcr\u00fcn\u00fc \u00e7ekerken CustomGraphQLCache<\/code> \u00fczerinden ge\u00e7erek \u00f6nbelle\u011fi kullan\u0131r. E\u011fer \u00fcr\u00fcn \u00f6nbellekte yoksa, productService<\/code> \u00fczerinden y\u00fcklenir ve \u00f6nbelle\u011fe eklenir.<\/p>\n\u00d6nbellek Stratejileri ve Optimizasyon<\/h2>\n
Veri Tutarl\u0131l\u0131\u011f\u0131 ve TTL\/TTI Ayarlar\u0131<\/h3>\n
expireAfterWrite<\/code> (TTL - Time To Live) ve expireAfterAccess<\/code> (TTI - Time To Idle) gibi se\u00e7enekler sunar. TTL, bir \u00f6\u011fenin \u00f6nbelle\u011fe yaz\u0131ld\u0131ktan sonra ne kadar s\u00fcre kalaca\u011f\u0131n\u0131 belirlerken, TTI, bir \u00f6\u011fenin son eri\u015fimden sonra ne kadar s\u00fcre kalaca\u011f\u0131n\u0131 belirler. Do\u011fru de\u011ferleri se\u00e7mek, verinin ne kadar s\u0131k de\u011fi\u015fti\u011fine ve uygulaman\u0131n ne kadar \"taze\" veriye ihtiya\u00e7 duydu\u011funa ba\u011fl\u0131d\u0131r. \u00d6rne\u011fin, nadiren de\u011fi\u015fen statik veriler i\u00e7in uzun TTL'ler, s\u0131k de\u011fi\u015fen veriler i\u00e7in k\u0131sa TTL'ler tercih edilmelidir.<\/p>\n\u00d6nbellek Boyutu ve Eviction Politikalar\u0131<\/h3>\n
maximumSize<\/code> veya maximumWeight<\/code> gibi ayarlar kullanarak \u00f6nbelle\u011fin belirli bir boyutu a\u015fmas\u0131n\u0131 engelleyebilirsiniz. Caffeine, bu s\u0131n\u0131rlar a\u015f\u0131ld\u0131\u011f\u0131nda hangi \u00f6\u011felerin at\u0131laca\u011f\u0131n\u0131 (evict) belirlemek i\u00e7in geli\u015fmi\u015f algoritmalar (\u00f6rn. Window TinyLfu) kullan\u0131r. Bu algoritmalar, en az kullan\u0131lan veya en az eri\u015filen \u00f6\u011feleri atarak \u00f6nbellek isabet oran\u0131n\u0131 optimize etmeye \u00e7al\u0131\u015f\u0131r. \u00d6nbellek boyutunu belirlerken, mevcut bellek kaynaklar\u0131 ve \u00f6nbelle\u011fe al\u0131nacak veri miktar\u0131 aras\u0131nda bir denge kurulmal\u0131d\u0131r.<\/p>\n\u00d6nbellek B\u00f6l\u00fcmlendirme (Partitioning)<\/h3>\n
@Cacheable<\/code> anotasyonunun value<\/code> parametresi ile bu b\u00f6l\u00fcmlendirme kolayca yap\u0131labilir.<\/p>\n\u00d6nbellek Ge\u00e7ersiz K\u0131lma (Invalidation) ve Y\u00f6netimi<\/h2>\n
Manuel Ge\u00e7ersiz K\u0131lma<\/h3>\n
@CacheEvict<\/code> anotasyonu bu ama\u00e7la kullan\u0131l\u0131r:<\/p>\n\nimport org.springframework.cache.annotation.CacheEvict;\nimport org.springframework.stereotype.Service;\nimport reactor.core.publisher.Mono;\n\n@Service\npublic class ProductService {\n\n \/\/ ... (getProductById metodu)\n\n @CacheEvict(value = \"products\", key = \"#product.id\")\n public Monocache.invalidate(key)<\/code> veya cache.invalidateAll()<\/code> metodlar\u0131 kullan\u0131l\u0131r.<\/p>\nOlay Bazl\u0131 Ge\u00e7ersiz K\u0131lma<\/h3>\n
\u00d6nbellek \u0130zleme ve Metrikler<\/h3>\n
recordStats()<\/code> yap\u0131land\u0131rmas\u0131 ile \u00f6nbellek isabet\/ka\u00e7\u0131rma oranlar\u0131, y\u00fckleme s\u00fcreleri gibi detayl\u0131 istatistikler sunar. Bu istatistikler, uygulaman\u0131n \u00f6nbellek kullan\u0131m\u0131n\u0131 optimize etmek i\u00e7in de\u011ferli bilgiler sa\u011flar ve Prometheus, Grafana gibi izleme ara\u00e7lar\u0131yla entegre edilebilir.<\/p>\n\n@Configuration\n@EnableCaching\npublic class CacheConfig {\n\n @Bean\n public CacheManager cacheManager() {\n CaffeineCacheManager cacheManager = new CaffeineCacheManager();\n cacheManager.setCaffeine(Caffeine.newBuilder()\n .expireAfterWrite(10, TimeUnit.MINUTES)\n .maximumSize(1000)\n .recordStats()); \/\/ \u0130statistikleri kaydetmeyi etkinle\u015ftir\n return cacheManager;\n }\n}\n<\/pre>\nSonu\u00e7<\/h2>\n
SSS (S\u0131k Sorulan Sorular)<\/h2>\n
1. WebFlux uygulamalar\u0131nda neden Caffeine kullanmal\u0131y\u0131m?<\/h3>\n
AsyncCache<\/code> aray\u00fcz\u00fc sayesinde, \u00f6nbellek y\u00fckleme i\u015flemlerini engellemeden ger\u00e7ekle\u015ftirebilir, bu da reaktif ak\u0131\u015flar\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar.<\/p>\n2. GraphQL'de \u00f6nbellek anahtar\u0131 nas\u0131l olu\u015fturulmal\u0131?<\/h3>\n
3. Caffeine'i da\u011f\u0131t\u0131k bir \u00f6nbellek olarak kullanabilir miyim?<\/h3>\n
4. \u00d6nbellek isabet oran\u0131 (hit ratio) d\u00fc\u015f\u00fckse ne yapmal\u0131y\u0131m?<\/h3>\n
\n
maximumSize<\/code> veya maximumWeight<\/code> de\u011ferlerini art\u0131rmay\u0131 d\u00fc\u015f\u00fcn\u00fcn.<\/li>\nexpireAfterWrite<\/code> veya expireAfterAccess<\/code> s\u00fcrelerini uzatmay\u0131 deneyin, ancak veri tutarl\u0131l\u0131\u011f\u0131n\u0131 g\u00f6z \u00f6n\u00fcnde bulundurun.<\/li>\n5. Caffeine'in bellek kullan\u0131m\u0131 nas\u0131l izlenir?<\/h3>\n
recordStats()<\/code> yap\u0131land\u0131rmas\u0131 ile \u00f6nbellek istatistikleri sunar. Bu istatistikler, bellek kullan\u0131m\u0131 hakk\u0131nda do\u011frudan bilgi vermese de, \u00f6nbellek isabet\/ka\u00e7\u0131rma oranlar\u0131 ve y\u00fckleme s\u00fcreleri gibi metrikler dolayl\u0131 olarak \u00f6nbelle\u011fin bellek \u00fczerindeki etkisini anlaman\u0131za yard\u0131mc\u0131 olur. Daha detayl\u0131 bellek izlemesi i\u00e7in JVM metriklerini (Heap kullan\u0131m\u0131 vb.) izleyen ara\u00e7lar\u0131 (JMX, VisualVM, Prometheus) kullanman\u0131z gerekir.<\/p>\n","protected":false},"excerpt":{"rendered":"Modern web uygulamalar\u0131, \u00f6zellikle mikroservis mimarileri ve yo\u011fun veri ak\u0131\u015flar\u0131yla kar\u015f\u0131 kar\u015f\u0131ya kald\u0131\u011f\u0131nda, performans ve yan\u0131t s\u00fcresi kriti…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-36560","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n