Redis Kullanımı – Süper Hızlı Bir Veritabanı

Yoğun istek neticesinde veritabanından çekilip kullanıcılara sunulan stabil dataların ortaya çıkarmış oldukları maliyeti minimize etmek için uygulamayı barındıran sunucunun memorysinde(bellek)(RAM) geçici olarak kaydedilip, kullanılmasıdır.

Nasıl Çalışmaktadır?

Kullanıcıda gelen istek üzerine gösterilecek data ilk olarak cache üzerinde kontrol edilir ve varsa buradan çekilip gönderilir. Eğer cache boş ise ilgili data veritabanından elde edilerek öncelikle cache’e kaydedilir, ardından kullanıcıya gönderilir. Bu süreçten sonraki yapılan tüm isteklere cache üzerinden data iletilecektir. Tabi ki de burada cachelenecek data miktarı sunucunun RAM özelliklerine ve özellikle kapasitesine bağlıdır.

Bir uygulamanın aynı veritabanından beslenecek şekilde birden fazla ayağa kaldırılan instance’larında eğer ki In-Memory Cache’i kullanıyorsanız olası veri tutarsızlığı ihtimali söz konusu olabilmektedir.

Şöyle ki; yandaki görseli incelerseniz bir uygulamanın A ve B olmak üzere aynı veritabanından beslenen instancelarını görmektesiniz. Kullanıcıdan gelen istekleri load balancer yoğunluğa göre bu instancelar arasında paylaştığını ve herhangi bir (T) zamanında gelen istek üzerine A’nın ve (T + 15) zamanında gelen istek üzerine B’nin in-memory caching yaptığını varsayalım. Bu caching işlemi neticesinde veritabanında herhangi bir modifikasyon söz konusu olabilme ihtimalini hesaba katarak, (T + 30). zamanında bu instanceların her ikisine de göz atıldığında aynı veri gözlemleniyorsa sıkıntı olmayacaktır. Lakin farklı veriler mevzu bahisse işte burada bir handikap söz konusu olacaktır. Düşünsenize! Load balancer’ın A instance’ına yönlendirdiği kullanıcı “Elma” görürken, B instance’ındaki ise veritabanındaki veriler modifiye edildiği için “Armut” görüyor.

İşte in-memory caching kullanıldığında olası olabilecek veri tutarsızlıkları bu durumlarda ceyran etmektedir. 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.

Peki bu handikabı nasıl çözebiliriz?

Bu handikaba %100 olmasada kısmi olarak Session Sticky(Yapışkan Session) ile çözüm getirilebilmektedir. Şöyle ki; Load balancer’a ‘X kullanıcısından gelen isteği A instance’ına gönderdiysen, bunda sonraki tüm X’den gelenleri A instanceına gönder’ diyerek var olan veri tutarsızlığını kısmi olarak çözmüş olabiliriz. Artık tüm kullanıcılar sadece ilk giriş yaptıkları instance üzerinden işlem yapabileceklerinden dolayı instancedan instance’a fark eden veri tutarsızlığının farkına varamayacak ve bizde böylece esasında farklı instancelarda devam eden bu tutarsızlığın sözde kullanıcı seviyesinde üstünü örtmüş olacağız. Tabi ki de bu yöntem tavsiye niteliğinde bir çözüm olmayacaktır!

Bir diğer yöntem olarak bu tarz farklı instancelar üzerinden yapılan yayınlarda tüm kullanıcılara cache’den en tutarlı veriyi gösterebilmek için cachelerin merkezi bir yere kaydedilmesi gerekecektir. Bunun için de bir sonraki yazımızın konusu olacak olan Distributed Caching kullanılmalıdır.

Nihai olarak, in-mermory cache’in ne olduğuna dair tam teferruatlı teoriye kalem tükettiğimizin kanaatindeyim. Bir önceki cümlede bahsettiğim gibi bir sonraki makalemizde Distributed Caching yapılanmasının ne olduğuna dair gerekli teorileri ortaya koyacağımızı tekrar hatırlatırım…