Redis 2 - In Memory Caching
SelamünAleyküm, geçtiğimiz yazıda Caching'e giriş yapmış ve caching nedir, neden caching kullanmalıyız ve caching yaparken nelere dikkat etmeliyiz sorularına kısaca cevap vermiştik. Bu yazıda ise In Memory Caching konusunu ele alıp teorip olarak bir inceleme yapacağız.
In Memory Caching Nedir?
Yapılan yoğun request'ler ( istekler ) sonucunde veritabanından çekilen ve kullanıcılara sunulan istikrarlı verilerin orataya çıkarmış olduğu maliyeti en aza indirgemek için uygulamayı barındıran ilgili server'ın ( sunucunun ) ram'inde ( Random Access Memory ) geçici olarak saklanıp kullanıması işlemine denir.
Nasıl Çalşır?
 |
Kullanıcıdan gelen request'e istinaden gösetrilecek veri cache (ön bellek ) üzerinde kontrol edilir ve varsa buradan alınıp gönderilir. Eğer cache boş ise ilgili veri temin edilerek öncelikle cache'e kaydedilir. ardından kullanıcıya iletilir. Bu süreçten sonra yapılacak olan tüm request'lerde veriler cache üzerinden kullancılara iletilecektir. Tabi cache'lenecek veri miktarı server'in Ram'in |
|
özelliklerine ve bilhassa kapasitesine bağlıdır. |
|
Olası Dezavantajı Nedir?
|
Bir uygulamanın aynı veri tabanından beslenecek şekilde birden fazla ayağa kaldırılan istance'larında eğer ki In Memory Cache kullanılıyorsa olası veri istikrarsızlığı söz konusu olabilir. Şöyle izah edilebilir; sağ taraftaki görselde bir uygulamanın A ve B olmak üzere aynı veri tabanına bağlı instance'larımızı görürsünüz. Kullanıcıdan gelen request'leri load balancer ( yük dengeleyici ) |
 |
|
yoğunluğa göre bu instance'ler arasında paylaşıldığı ve herhangi bir (T) zamanında gelen request üzerine A'nın (T + 15) zamanında gelen request üzerine B'nin in-memory caching yaptığını varsayalım. Bu caching işlemi sonucunda veri tabanında herhangi bir tahavvül söz konusu olma ihtimaline karşın, (T + 30) zamanında bu instance'ların her ikisine de göz gezdirildiğinde aynı veri gözlendiğinde herhangi bir sorun teşkil etmeyecektir. Lakin farklı veriler gözlenmişse burada bir handikap söz konusu olmuş demektir. Bu durumu tahayyül ettiğimzde Load Balancer'ın A instance'sına yönlendirdiği kullanıcı "Araba" görürken, B instance'indaki ise veri tabanındaki veriler tahavvül edildiğinden "Motorsiklet" görüyor. |
|
|
In Memory Caching kullanımıda olası veri istikrarsızlığı durumdan meydana gelmektedir. Tabi ki de in-memory caching yapılan uygulamanın tek bir instance’ı üzerinden yayın gerçekleştiriliyorsa aynı ayna tüm kullanıcılarda sadece o instance üzerinden işlemlerini gerçekleştireceğinden dolayı bu handikap söz konusu olmayacaktır. |
|
Bu Dezavantajı Nasıl Çözülebilir?
 |
Bu handikaba tam anlamıyla olmasada Session Stick ( Yapışkan Session ) ile kısmi bir çözüm getirebiliriz. Şöyle ki; Load balancer'a X kullanıcısından gelen request'i A instance'sına gönderdiysek, bundan sonraki X'ten gelenleri A instance'sına ilet diyerek var olan veri istikrarsızlığını kısmi olarak çözüm getirşimiş olabiliriz. Bundan böyle tüm kullanıcılar sadece ilk giriş yaptıkları instance üzerinden işlem yapabileceklerinden ötürü instance'tan instance'a fark eden veri istikrarsızlığının |
|
farkına varamayacak ve bizde böylelikle farklı instance'larda devam eden bu istikrarsızlığın görünürde kullanıcı bazında üstünü örtmüş oluruz. ( Uygulayıp uygulamamak size kalmıştır.) |
|
Diğer bir yöntem ise buna benzer farklı instancelar üzerinde yapılan yayınlarda tüm kullanıcılara cache'den en istikrarlı veriyi iletebilmek üzere cache'lerin merkezi bir ortamda saklanması gerekir. Sonraki yazımızda olacak olan Distributed Caching konusunda bu durumu ele almış olacağız.
Bu yazımızın sonuna geldik. Şimdiye kadar In-Memory konusunu teorik olarak incelemiş olduk bir sonrkaki yazıda Distributed Caching konusunu ele alacağız. İlgilenenlerin faydalanması ümidiyle.
Blog Listesi