Keep your cache fresh!

We usually store our data in a relational databases for persistency.But what do we really do for prevent performance problems in high traffic applications? We develop faster and more robust applications by using caching.On the other hand, We usually use  cache-aside programming pattern.

Lets assume that,

We use the following algorithm to get data at any point in the application.

  • check local memory
  • else check redis, and update local memory
  • else fetch from source, and update redis and local memory

What are we going to do with any data change in the source? How do we keep our memory fresh?

At this point, redis will save us.

let’s look at the solution below

 

I will share the source at github as soon as possible.

happy coding!

 

 

 

HTTP/2 : Herşey zamanla değişir

Bilindiği üzere 1999 yılından bu yana HTTP/1.1 protokolunu kullanıyoruz.Teknoloji evren gibi sonsuz yönlü genişleyen bir ekosistem olduğu için HTTP protokolüde versiyon geçişleri ile kendini güncelliyor.Gelinen bu noktada HTTP/2 kullanıma sunulmuş durumda.

HTTP/2 ile gelen başlıca özellikler şunlar;

  • HTTP/1.1 concurrent olarak sunucuya belirli bir sayıda request gönderilebiliyordu.Artık multiplexed özelliği ile bu kısıtlama kaldırıldı.Buda özellikle sayfaların client tarafında yüklenmesi hızını arttıracaktır.
  • HTTP/1.1 Request için body comparison yapılabiliyordu.Fakat özellikle Headerlar için bu mümkün değildi.Buda veri transferi sırasında boşuna kaynak israfına sebep oluyordu.Bu noktada artık Header compression desteği geldi.
  • HTTP/1.1 protokolünde iletişim metin halinde gerçekleşiyordu.Artık iletişim binary olarak gerçekleşecek.Bu da iletişimin eskisinden daha hızlı bir biçimde gerçekleşmesi anlamına geliyor.
  • Server-Push bu özellik biraz karmaşık lakin kısaca client tarafından herhangi bir request olmadan sunucu tarafında veya sunucu içerisinde iletişim sağlanabilecek.

 

Bunun dışında deyinemediğim bir çok özellik mevcut.Daha detaylı açıklamalara bu adresten erişebilirsiniz.

Ayrıca Go için ilgili protokolü destekleyen güzel bir frameworkte var.

Sevgiler,

Cem

 

Akka.NET – Bakış Açını Değiştir

Akka’nın temelini oluşturan aktör ekosistemi, 2006 yılının temmuz ayında Philipp Haller tarafından  scala’nın bir bileşeni olarak geliştirildi.Fakat şuanki hali Jonas Bonér‘in 2009 yılında başladığı çalışmaların devamı olarak nitelendirilmektedir.Bu noktada Akka’nın benim dikkatimi çeken ve güçlü altyapılar oluşturmak için geliştirilmiş bir kaç özelliğini bulunuyor.Bu özellikler;

  • Mesaj Tabanlı çalışma / iletişim prensibi
  • Birbirini etkilemeyen birden fazla birleseni veya işlemi bir arada bulundurma ve çalıştırabilmesi
  • Yüksek Performanslı olması
  • Ölçeklenebilir olması
  • Gerçek Zamanlı olarak çalışabilmesi
  • Dağıtık mimarilere veya yapılara destek verebilmesi
  • Dinamik olması
  • Asenkron işlemlere destek vermesi

Bu noktada Akka ile ilgili bence dikkat edilmesi gereken en önemli husus; bugüne kadar fonksiyonel,prosedürel veya nesneye yönelik programlama dilleri ile uğraştıysanız Akka ekosistemi bunlarından biraz farklı bir yapıya sahip olmasıdır.Akka temel olarak aktör ekosistemi üzerine kurulmuş bir yapıya sahiptir.Bu sebepten Akka ekosistemine giriş yapmadan evvel bakış açımızı değiştirmemiz gerekiyor.

Aktör Nedir?

Aktör kavramını gerçek hayata uyarlayacak olursak;aktörler,tıpkı insanlar gibi birbirleri ile iletisim icerisinde olan ve birbirleri ile çalışabilen varlıklardır.Bu noktada aktörler aralarındaki bu iletişim insanlardaki iletişim becerisine benzer bir özellik ile yani mesajlar ile gerçekleştirmektedirler.Bunun dışında tıpkı insanlar gibi her aktörün kendine ait bir hafızası ve kendine ait mesajları saklayabileceği bir mesaj kutusu vardır.Öte yandan aktör ekosistemi içerisindeki herşey birer aktördür.Nesneye yönelik programlama diline aşina olanların bildiği üzere ekosistem içerisindeki herşey birer nesnedir.Aynı yaklaşım Akka içinde geçerlidir.Aktör ekosistemi içerisinde yer alan herşey bir aktördür.Akka ekosistemi içerisinde birden fazla aktör tipi bulunmaktadır.Fakat bütün aktör tipleri UntypedActor‘den türetilmiştir.

Mesaj Nedir?

Akka ekosistemi içerisindeki aktörler arasındaki iletişimin mesajlar sayesinde gerçekleştiğini belirtmiştim.Bu noktada mesajlar nesne olarak tanımlanmıştır.Yani aktörler arasındaki iletişimi sağlayacak mesajlar string,int,float vb. veya özelleştirilmiş sınıflar olabilir.Burada bilinmesi gereken en önemli konu mesajların immutable olduğudur.Burada mesajların immutable olmasının en önemli sebebi  thread-safe bir ekosistem oluşturmaktır.

Aktörler arasındaki iletişim

Herhangi iki aktör birbirleri ile iletişime geçtiklerinde bu iletişim sırasında  birbirlerini tanımak zorunda değillerdir.İletişim tamamı ile aktörlerin belirtilen adresleri üzerinden gerçekleştirilir.Yani aktör ekosistemi içerisindeki iletişimin sağlanabilmesi için aktörlerin yalnızca adreslerinin bilinmesi gerekmektedir.Buna Location transparency yani konum şeffaflığı denir.Akka içerisindeki adres yapısı aşağıdaki görseldeki gibidir.

Yukarıdaki görsel üzerinde yer alan kavramları kısaca açıklayacak olursak,

  • Protokol : Ekosistem içerisindeki aktörlerin hangi protokol üzerinden haberleşeceklerini belirtmek adına kullanılmaktadır.Http,Https,Tcp,Udp gibi bir çok protokol kullanılabilir.Eğer ekosistemin iletişimi için remoting yada clustering kullanılıyorsa iletişim soket iletişim protokolleri olan tcp yada udp ile sağlanmalıdır.
  • ActorSystem : Akka içerisindeki her aktör sisteminin bir adı bulunmalıdır.Belirtilen bu ad üzerinden sistem içerisindeki iletişim gerçekleştirilir.
  • Address : Eğer sisteminizi remoting üzerinde kurmadıysanız adres kavramını yok sayabilirsiniz.Lakin remoting üzerinde kurulmuş olan ve birbirleri ile iletişim halinde olan aktör sistemlerinin IP adresleri,Domainleri ve varsa Portları belirtilmelidir.
  • Path : Aktörün ekosistem içerisindeki yerini belirtmek adına kullanılmaktadır.Burada bir endpoint olarak düşünülebilir.Genel olarak REST API DESIGN kuralları burada da kullanılabilir.

Her bir aktörün kendine özgü bir mesaj kutusu olduğunu belirtmiştik.Bu noktada aktörler arası iletişim sırasında mesajlar direkt olarak işlenmez.Öncelikle iletişim için kullanılan mesaj ilgili aktörün mesaj kutusuna düşer.Aktörlerin mesaj kutuları FIFO prensibi ile çalışır.Yani ilk gelen mesaj ilk olarak çıkar.Burada mesaj kutusu aktörlerin mesajları işlemesini bekler.Bir mesaj işlendiğinde diğer mesajı aktörün ilgili metoduna gönderir ve işlem devam eder.Aktörler aynı anda yalnızca bir mesaj işleyebilirler.Buradaki temel amaç thread-safety kavramına tam anlamı ile elverişli olabilmektir.

Aktör ekosistemi nasıl çalışır ?

Aktör ekosistemi yukarıdaki görselde belirtilen akış ile çalışmaktadır.Aktörler arasındaki parent-child ilişkisi vardır ve her aktörün bir parent’ı bulunmaktadır.Parent olarak belirlenen aktörler child aktörleri yönetirler(supervising).Burada bilinmesi gereken en önemli kavram bu akış içerisindeki ekosistemde yer alan herhangi bir aktörün beklenmedik bir hata ile karşılaşması durumunda aktörün supervisor’ı olarak belirtilen diğer aktör bu döngüyü ilgili aktör için yeniden başlatır.Bu gibi durumlarda ilgili mesajlar aktörlerin mesaj kutusunda tutulduğu için herhangi bir veri kaybı yaşanmaz.

 

Ayrıca ekosistem içerisinde yukarıda belirtilen akışta gösterilmeyen fakat ekosisteme dahil olan başka kavramlarda bulunur.Bu kavramlar aşağıdaki görselde belirtilmiştir.

 

Son olarak aktörler çalışmadıkları sürece sistem kaynaklarını tüketmezler.Yani reactive bir yapı ile çalışırlar.Bunun dışında aktörlerin kullanım maliyetleri oldukça düşüktür.2.5 milyon aktörü yalnızca 1 gigabytelık bir ram üzerinde çalıştırabilirsiniz.

Örnek

Aktör ekosistemi ile ilgili basit bir örnek yapalım.Bir elektronik ticaret altyapısı tasarladığımızı varsayalım.Altyapımıza sipariş sonrası kullanıcıya bilgilendirme maili gönderecek bir modül ekleyelim.Bu noktada ekosistem yalnızca sipariş ve bildirim aktörlerinden oluşacaktır.

Bu senaryomuzda, Sipariş numarası oluştuktan sonra ilgili numara ile sipariş sahibi kullanıcıya bildirim gönderilecektir.

Öncelikle çok basit bir bildirim modeli ve ilgili modeli referans alan bir bildirim aktörü tasarlıyoruz.

Yukarıda tanımladığımız bildirim aktörüne sipariş aktörü tarafından mesaj gönderildiğinde bildirim aktörü ilgili mesajı öncelikle kullanacağı tipe çevirecektir.Daha sonra bildirim ile ilgili işi yapacaktır.Bildirim aktörümüzden sonra sipariş aktörümüzü tanımlayalım.

Son olarak oluşturduğumuz iki aktörü ekosistemimize ekleyelim.

Uygulama çalıştığımda ekrana aşağıdaki bilgileri yazacaktır.

The notification is ready
Notification Number : 73ba27bb-6059-4cad-b3cd-454fbf7a2200
To : Cem Basaranoglu
Content : Thank you for choosing us.You can follow your order with order number.Order Number : 673a0226-5ffa-4f59-bbbf-94e23c36aace

Bu noktada ilgili aktörler ve ekosistem geliştirilebilir.Sipariş ekosisteminde bir sonraki mesajın işlenmesi için emri yollayan Self.Tell komutu siparişleri takip etmek amacı ile alt bir aktörü tetikleyebilir.Bu örnek yalnızca temel olarak sistemin nasıl çalıştığını açıklayabilmek adına geliştirilmiştir.

Sevgiler,

Cem

Kaynaklar