Problemin tanımı basit.

Resimdeki masada 5 tane filozof oturduğunu düşünün. Filozoflarımızın yaşam şifreleri çok basit. Düşünüyorlar, acıkınca da yemek yiyorlar. Sonra tekrar düşünmeye devam ediyorlar; sonra tekrar yemek yiyorlar. Sonsuza kadar gidiyor bu durum.

Masada ise sadece 5 tane çatal var. İşin tricky kısmı ise şu; bir filozof ortadaki makarnayı yemek için 2 tane çatala ihtiyaç duyuyor.

Dolayısıyla bir filozofun yaşam döngüsü şu şekilde:

while True:
    dusun();
    catallari_al();
    makarnayi_vur();
    catallari_birak();

Çözmemiz gereken problem ise şu:

Tüm filozoflar aynı anda yemek yemeye kalkarsa sofrada yeterince çatal (resource) yok. Dolayısıyla, bu filozofların yönetimi, kaynak paylaşımı nasıl olmalı ki, yemeye niyetlenen bir filozof mutlaka -eninde sonunda- iki çatal elde edip yemeğini yiyebilmeli.

Dikkat etmemiz gereken şeyler:

1. Filozoflar(Threadler) arasında Deadlock oluşmamalı. Örneğin, sonsuza kadar birbirini bekleyen filozoflar (Bırak şu çatalı da yiyelim!)
2. Herhangi bir filozof aç kalmamalı. (4 tanesi götürdü, vurdu makarnaları, biri aç kaldı. Olur mu? Olmaz.)
3. Aynı anda birden fazla filozof makarna yiyebilmeli.

Filozof Sınıfı

Filozofların hangi çatalları alıp kullanmaları gerektiği konusunda 2 yardımcı metod yazalım. isimleri left ve right olsun.

class Philosopher:

    def __init__(self, *args, **kwargs):
        self.index = kwargs.pop("index")

    @property
    def left(self):
        return self.index

    @property
    def right(self):
        # when it gets to 5, (4 + 1) % 5 = 0
        return (self.index + 1) % 5

Her filozofun 0..4 arası index'i olduğunu varsayarsak; çatalları da bu indexle aynı şekilde ilişkilendirebiliriz.

left metodu; filozofun numarası ile aynı sonucu versin. 4.filozof sol eline 4.çatalı alsın.
right metodu ise mod5'e gore index+1'i versin. 4.filozof, sağ eline 0. çatalı alacak bu şekilde. (masa yuvarlak, filozof ve çatal sayısı 5.)

class Philosopher:

    def __init__(self, *args, **kwargs):
        self.index = kwargs.pop("index")

    @property
    def left(self):
        return self.index % 5

    @property
    def right(self):
        # when it gets to 5, (4 + 1) % 5 = 0
        return (self.index + 1) % 5

çatalları ise, bir liste halinde hepsi birer semafor olacak şekilde tanımlayalım. (Semafor kullanıyoruz, zira 2 filozof aynı anda, aynı çatala meyledebilir, critical section'da kavga etmesinler.)

forks = [Semaphore(1) for i in xrange(5)]

Filozofa ekleyeceğimiz sadece 2 metod kaldı. getforks(), ve putforks()

getforks() -> çatalları al, yemeye başla.
putforks() -> yemeni bitir, çatalları geri bırak.

def get_forks(self):
    self.forks[self.left].acquire()
    self.forks[self.right].acquire()

def put_forks(self):
    self.forks[self.left].release()
    self.forks[self.right].release()

Bir filozof, çatal alacağı zaman önce solundaki çatalı bekliyor. Eğer çatal boştaysa (Semaforlar sağolsun) alıyor, sonra sağdaki çatalı bekliyor. Eğer o da boştaysa amenna, direkt makarnayı göturmeye başlıyor. (random çalışma süresi olan bir self.eat metodu ile)

Çatallara erişim semaforlar tarafından kontrol edildiği için her şey güzel gibi. Kodların çalışan, derli toplu hali dining-philosophers-deadlock.py üzerinde var.

Bu kodu 3-5 defa çalıştırın sisteminizde python varsa. Birkaç denemeden sonra şöyle bir deadlock ile karşılaşacaksınız.

$ python dining-philosophers-deadlock.py

1 got the left fork 1
2 got the left fork 2
4 got the left fork 4
0 got the left fork 0
3 got the left fork 3

Tüm filozoflar, aynı anda sol çatallarını aldı. Sağdaki çatalın boşalmasını bekliyor. Ama boşa düşmeyecek hiçbiri; zira, hepsi beklemede.

Bu duruma terminolojide deadlock diyoruz. Grup halinde threadlerimiz, sürekli askıda birbirlerinden işlem bekliyorlar.

Çözüm

65'ten bu yana bu problem çokca tartışılmış ve çeşitli çözümler getirilmiş. Ben en beğendiğim çözümü uygulayacağım.

Aynı anda maksimum 4 filozofa işlem yapma izni verirsek, bu durumdan kurtulabiliriz. En kötü ihtimalle 4 filozof birden de sol çatalı kaldırsa, 1 tane sağ çatal boşta olacak; ve filozoflardan biri yemeye devam edebilecek.

Az önce yazdığımız koda ufak bir değişiklik yaparak bu durumu elde edebiliyoruz.

multiplex = Semaphore(4)

diye bir semafor daha tanımlayıp;

def get_forks(self):
    self.multiplex.acquire()
    self.forks[self.left].acquire()
    self.forks[self.right].acquire()


def put_forks(self):
    self.forks[self.left].release()
    self.forks[self.right].release()
    self.multiplex.release()

Filozofların çatalları aldığı yerde, multiplex'in değerini bir düşürüp, çatalları bıraktığı yerde ise multiplex değerini bir arttırıp aynı anda maksimum 4 filozofun yeme işlemiyle meşgul olabileceğini karara bağlamış oluyoruz.

Terminojide bu pattern'e ise multiplex deniyor.

Örneğin bir cafe sahibisiniz. Ağırlayabileceğiniz kişi sayısı belli. Aynı anda cafenizde N kişi bulunabilir. Cafenizin içerisini de critical section olarak düşünün. Bu durumda Semaphore(N) gibi bir semafor yardımıyla, içerdeki kişilerin hesabını tutar, gereğinden fazla yük altında kalmazsınız.

Çözümün derlenmiş toplanmış, çalışır hali ise dining-philosophers-multiplex.py adresinde. Başka semafor puzzle'ları ile ilgilenirseniz de repoya bekleriz.

Problemle ilgili diğer detaylara ve diğer çözümlere ise wikipedia/Diningphilosophersproblem üzerinden ulaşabilirsiniz.

"I strike from the shadows!"

Bu arkadaşın adı dark templar. Kendisi, starcraft evreninde acımasız bir adamdır. Normal zamanlarda kendisini göremezsiniz. "invisible" bir ünitedir.

Bu arkadaş bir çok ünitenizi tek vuruşta keser. Bu yüzden savunma olarak detection yapabilen bir üniteye sahip olmanız gerekir. Dark templar rush olarak bilinen stratejiye nice yiğitler heba olmuştur.

Bu arkadaşın adı da observer. Kendisi, protoss mühendislerinin ürettiği etkili bir drone'dur. Savaş alanında olan bitenleri gözlemleyip, protoss arşivlerine iletir.

Hem görünmez olup, hem de "dark templar" gibi üniteleri detect (tespit) edebilir.

Bu çirkin şey ise raven. Bu da terranların drone'u. Uzaktan bir terran pilotu tarafından kontrol edilir. Ama içerisinde mükemmel bir AI (yapay zeka) bulundurur. Drone içerisindeki bir çok konuya kendisi karar verir ve ayarlar. (Sıcaklık, Genel savaş durumu, enerji seviyeleri ve dış tehditler gibi.)

1 saniye içerisinde milyarlara varan komutu işleyebilir bir cpu'ya sahiptir. Birçok terran mühendisi, AI'sinin bu derece güçlü olmasından dolayı (bağımsız karar verebilme) tamamen bağımsız duruma geçebileceğinden ve felaketlere yol açabileceği şeklinde rapor vermiş.

Ama çok şükür iş daha terminator'e dönmemiş durumda. Şimdilik, raven gayet sadık bir ünite.

Bu arkadaş da, dark templar gibi görünmez ve saldırgan üniteleri tespit ettiği için terran taburları genelde 1 tane yanında bulundurur.

Bu arkadaş da Serdar Ortaç.

İçinde "Serdar Ortaç" bulunan evrene dönüyoruz... Yıl 95-96. Blizzard'ın ofisindeyiz. Yazılımcılar, gün içinde sigara-kahve molaları ve goygoylardan kalan zamanlarda ufak ufak kod da yazıyorlar.

İşin tespit edilme, detection'a sıra geldiğinde şöyle bir yapı kuruyorlar.

Demişler ki, Dark Templar bir nesne olsun. InvisibleUnit sınıfını extend etsin. InvisibleUnit, haritadaki observerları kendisine register etsin. Onların görüş alanına girdiğinde desin ki "ben geldim!".

InvisibleUnit sınıfı

class InvisibleUnit(object):

    def __init__(self):
        self.observers = []

    def register(self, observer):
        if not observer in self.observers:
            self.observers.append(observer)

    def unregister(self, observer):
        if observer in self.observers:
            self.observers.remove(observer)

    def unregister_all(self):
        if self.observers:
            del self.observers[:]

    def on_observer_range(self, *args, **kwargs):
        for observer in self.observers:
            observer.saw_something(*args, **kwargs)

Dark templar sınıfı

from invisibleunit import InvisibleUnit

class DarkTemplar(InvisibleUnit):
    hp = 100
    damage = 50

InvisibleUnit'e ek olarak hp, damage gibi property'ler ekledik. İleride dark templar gibi başka görünmez üniteler de olabilir diye düşünmüşler çünkü.

InvisibleUnit sınıfı register metoduyla haritadaki observerları kendi içine dahil ediyor. Observerların görüş alanına geldiğinde de o listeyi dönüp kendini observerlara saw_something metodu üzerinden bildiriyor. (Basitlik açısından observerların haritada aynı yer üzerinde olduklarını varsayıyoruz.)

observer.py

from abc import ABCMeta, abstractmethod

class Observer(object):
    __metaclass__ = ABCMeta

    @abstractmethod
    def saw_something(self, *args, **kwargs):
        pass

ABCMeta, abstract method gibi şeyler python dahilindeki şeyler.

Basitçe observer sınıƒından türeyen observerların, saw_something metodunu implemente ettiğinden emin olmak istiyoruz.

protoss_observer.py

from observer import Observer

class ProtossObserver(Observer):
    def saw_something(self, unit_name, hp, damage):
        print "I saw a {}. (HP: {}, Damage: {}) - {} reported.".format(
            unit_name,
            hp,
            damage,
            self.__class__.__name__
        )

raven.py

from observer import Observer

class Raven(Observer):
    def saw_something(self, unit_name, hp, damage):
        print "I saw a {}. (HP: {}, Damage: {}) - {} reported.".format(
            unit_name,
            hp,
            damage,
            self.__class__.__name__
        )

Son olarak, test yapabileceğiniz bir main.py

from darktemplar import DarkTemplar

from protoss_observer import ProtossObserver
from raven import Raven

# dark templar
dt = DarkTemplar()

# protoss observer
protoss_observer = ProtossObserver()

# terran observer (Raven)
raven = Raven()


dt.register(protoss_observer)
dt.register(raven)

dt.on_observer_range(
    "Dark Templar",
    dt.hp,
    dt.damage,
)

Bu şekilde, observer yazılım desenini starcraft içinde basitçe
implemente etmiş olduk.

$ python main.py
I saw a Dark Templar. (HP: 100, Damage: 50) - ProtossObserver reported.
I saw a Dark Templar. (HP: 100, Damage: 50) - Raven reported.

Starcraft evreninden çıkıp, bizim evrene dönersek; herhangi bir gazeteye abonelik durumu observer desenini en iyi açıklayan senaryo, pub-sub dediğimiz modeldir. Gazete aboneliği düşünün.

Aboneler=Observer, Gazete=Subject(Observable) gibi. Subject'in, Observerlara karşı one-to-many bir ilişkisi bulunur.

1 Dark templar'ın, birden fazla gözlemcisi olabilir. (Raven, OverSeer, Protoss Observer gibi.)

Duruma göre, bu observerlar dinlemeyi bırakabilir. Bunu da ana subject sınıfında (unregister) yapabilirler. Observer deseninin isminden haber olmasanız da birçok problemi bu veya buna benzer bir şekilde çözmüşsünüzdür.

Dark Templarsız günler dilerim.

"Though we strike at you from the shadows, do not think that we lack the courage to stand in the light. - Dark Templar"

Yazıda bulunan kodların derli toplu hali: @emre/starcraft-observer-pattern

Neredeyse yazdığım kod kadar "yorum" yazmak gibi değişik bir takıntım vardı. Çünkü o şekilde daha güzel, daha profesyonel, daha bir roket bilimi gibi görünüyordu.

Yıllardır da "yazdığınız kodu anlatın" goygoyu sektörün içinde var. Hatta, stajyerlerin, işe yeni başlayanların aldığı yegane tavsiye; "kodlarına yorum yazmayı unutma, yoksa 6 ay sonra o kodu sen de anlamazsın!" goygoyudur.

Halbuki, pratikte ideal bir yazılım geliştirme sürecinde, kod tabanında mümkün olduğunca az yorum olmalıdır.

Sürdürülebilir ve bakımı yapılabilir kod, kendi kendini anlatmalıdır. Kötü programlama teknikleriyle bir implementasyon yapıp, daha sonra o implementasyonu kodtaki satır sayısı kadar anlatmanın bir mantığı yoktur.

Bir kod parçasının ne yaptığını ayrı bir şekilde anlatmak için yorum satırlarına ihtiyaç duymamalıyız. Yazılan kod, gerek isimlendirme, gerekse modern yazılım kuralları dahilinde, zaten kendi kendini anlatacak seviyede basit ve açık olmalıdır.

Ama gerçek dünyada, bu işi %100 yapabilmeniz zor. Bazen elimizde olmayan sebeplerden, bazen tembelliğimizden bu basitliği kaybediyoruz ve neyi niye yaptığımızı anlatmamız gerekebiliyor. hatta, yalan söylemeyelim, işyerlerimizde genelde "workaround" ve "quick hack" modelleriyle günü idare ediyoruz. :)

gereksizin gereksizi yorumlar

meyveler = ["Elma", "Armut", ]
# listeye Ayva ekle.
meyveler.append("Ayva")

Aferin. Laf söyledi balkabağı. Python'ın listeleri dünyanın en temiz API'sine sahip olduğu halde, bizim küçük wozniak python standart kütüphanesi içerisindeki veri tipini dökümente etmek istemiş.

Buradaki tek sorun bu da değil; yarın birgün meyveler listesine Ayvayla birlikte "Cilek" eklemek istek, kodu düzenlemenin yanında bir de üstündeki gereksiz yorumu güncel tutmaya çalışacağız.

phpdoc ve benzeri araçlar

"Kaynak kod üzerinden dökümantasyon çıkaralım" fikri ilk kimden çıktı bilmiyorum ama bu arkadaşlar kaynak kod kalabalığı yapmaktan başka bir tek şekilli HTML çıktıları almaya işe yarıyor olabilirler.

Dahası, koda yeni geliştirmeler yaptığınızda bakımını yapmanız gereken bir de docstring'ler olacak. ve tembellikten orayı güncellemeyeceğiz. (güncellemiyoruz da) bu sefer, zaten açıkta olan bir bilgiyi, yorumlar bize yanlış iletecek. dahası, sevgili IDE'lerimiz o docstringleri okuyup, bize yanlış type bildirimleri yapacaklar.

Bir fonksiyonun aldığı her parametre için dökümantasyona ihtiyacımız yok. fonksiyonun, parametrelerin isimlendirmesine dikkat etmek, parametre sayısını abartmamak gibi işler yaptığımızda zaten yine bu stringlere ihtiyacımız olmayacak.

bir versiyon kontrol sistemi olarak kod dosyaları

Bu tip bir kullanım umarım 2015 senesi itibariyle kalmamıştır, ama güzel bir anı olarak kalsın;

Çok uzun yıllar önce (belki 9-10 yıl?) ceviz.net'in ceviz.net olduğu zamanlarda site yazılımında her bir değişiklik yapıldığında değişikliği yapan kodun başına, tarih, değişen kısım, değiştiren kişi şeklinde not düşüyordu.

"""
* "zaa" hatasi duzeltildi. "zort" durumunu da dusunmekte fayda var. - emre, 21.12.2007

* emre'nin bozdugu yerleri duzelttim. - ansugo, 20.12.2006

* hicbirinizin anlamadigi bir seyler yaptim. -acemi, 19.12.2005
"""

Bir dosya üzerinde 15-20 iş yapıldığını düşünün. :)

Aşağıdaki gibi örnek bir fonksiyonumuz var.

def add_to_list(x):
    x.append(25)

fonksiyon basit. girdi olarak liste alıp, listeye 25 değerinde bir int ekliyor. Hemen fonksiyonu deneyelim:

>>> y = [15, ]
>>> add_to_list(y)

y’nin global alanda değerinin ne olmasını beklersiniz?

>>> y
[15, 25]

Bu şekilde bakarsak call by reference şeklinde gözüküyor. fonksiyonun içinde değeri değiştirdiğimiz halde genel scope’da baktığımızda da değer değişmiş durumda.

--

Başka bir deneme yapalım.

>>> def add_to_list(x):
... x = x + [25,]
... print x
... 
>>> y = [15]
>>> add_to_list(y)
[15, 25]
>>> y
[15]

Bu sefer baktığımızda fonksiyon scope’u içerisinde x, üzerinde oynanmış değere sahipken, fonksiyon scope’undan çıktığımızda x’in güncellenmediğini görüyoruz.

Bu fonksiyonu ele alırsak da model, call by value şeklinde gözüküyor?

Python iki modele de sahip değil. Bu durum, call by sharing veya call by object reference şeklinde geçiyor daha çok literatürde.

--

Python’da her şey — veri tipleri de dahil objedir.

>>> x = 42
>>> id(x)
14822312

Herhangi bir instantiation(örnekleme?) yapmasak da arkaplanda x bir objeden türetilerek oluşturulur. Bu nesnelerin hepsinin bir referansı olur ve referanslar da basit olarak hafızada hangi objenin nerede tutulduğunu tutar.

İlk yazdığımız fonksiyonu bir daha hatırlayalım:

>>> y = [15, ]
>>> def add_to_list(x):
... x.append(25)
...
>>> y
[15, 25]

add_to_list() fonksiyonu çalışmaya başladığında arkaplanda y nesnesinin referansı kopyalanıyor. birden fazla referans aynı nesneyi paylaşıyor.

İki referans da aynı nesneyi paylaştığı için, hangi referanstan olursa olsun bir değişiklik yaptığımız da aynı nesne etkilenecektir.

Peki ikinci fonksiyondaki fark ne? Bakalım.

>>> y = [15, ]
>>> def add_to_list(x):
... x = x + [25,]
... 
>>> add_to_list(y)
>>> y
[15]

Bu sefer fark fonksiyon içinde x’in yeni bir liste nesnesine atanıyor oluşu.

x = [15, ] + [25, ] şeklinden farkı yok. Farklı bir nesne, farklı bir referans demek, memory’de farklı bir yer demek.

--

immutable (değiştirelemez) objeler

immutable objeler bir kere yaratıldıktan sonra değiştirelemez objelerdir.

yazının başındaki fonksiyonlarda mutable veri tipi olan listeleri kullandık. immutable bir veri tipi kullanırsak senaryo yine değişiyor.

>>> y = "kazu"
>>> def add_to_string(x):
... x += "makino"
... 
>>> y
kazu

aynı işi listelerle yaptığımızda farklı olan senaryo string kullandığımızda değişti.

Aynı şekilde; iki referans aynı nesneyi (‘kazu’) paylaşsa da nesne immutable olduğu için değiştirilemedi. string, tuple, integer gibi değerler argüman olarak yollandığında — bu objeler özünde iyi ve immutable oldukları için, scope içine başka bir string nesnesi/referans yeni haliyle yerleştiriliyor.

-- Phil Karlton

"caching de nedir ki ya, bu kadar zor olan ne var?" diyorsaniz bu yazi tam size gore. proje buyudukce ve caching'e gercekten ihtiyaciniz olan durumlarda isin icine beklemediginiz problemler giriyor. (cache invalidation, dog piling) ya da aslinda farkinda olmadiginiz sorunlar icin
optimizasyonlar yapmaniz gerekebiliyor.

asagida genel bir caching pattern'i var, muhtemelen bu sekilde calisan kodu bircogumuz yazdik ve kullaniyoruz.

from django.core import cache

def get_post_data(post_id):
    cache_key = "post_{post_id}".format(post_id=post_id)

    post = cache.get(cache_key)

    if not post:
        post = Post.objects.get(pk=post_id)
        cache.set(cache_key, post, 1800)

    return post

anlik 40.000 trafigin oldugu bir web uygulamasi dusunun, anlik 40.000 kisi db'ye gitse eski ve guzel RDBMS'iniz sikinti yasayacak durumda. boyle bir problem yasanmansin diye ne var yok cache'e yukaridakine benzer bir pattern'le dayadiniz.

redis'le memcache ile concurrency'in dibine vuruyorsunuz, hatta sirketiniz yazilim etkinliklerine sponsor oluyor orada "nasil sistemi scale ettik?", "memcache'in ustunde nasil at kosturdum?" diye sunumlar yapiyorsunuz. groupie'leriniz oluyor, skype'da feyizli yazilim sohbetlerinde "abi scaling bizden sorulur, hatta mysql'i de ssd'ye aldik, parasini verdik ama degdi" diyorsunuz, buraya kadar her sey cok guzel.

problem #1: timeout

timeout, yuksek trafikli sistemlerde kullanilmamasi gereken bir ozellik. cache'leriniz mumkunse sonsuza kadar durmali ya da olabildigince uzun tutulmali sistemde.

dog piling -- veya thundering hard

tamamen yukaridaki kod uzerinden dusunun. post_42 key'li cache'iniz var, 1800 saniye gecti timeout oldu, bir kullanici geldi, cache sistemine baktiniz key yok, tekrar olusturdunuz, koydunuz sisteminize.

burada asil sikinti yuksek trafigin oldugu sistemlerde, post42 key'i database'den hesaplanip tekrar cache'e konulacak zamanda, bir degil, binlerce, onbinlerce kullanicinin o key'e istek yapmasi. bu da binlerce kullanici kadar database'e ayni anda gidis demek. bunu sadece bir post detayi icin dusunmeyin, anasayfadaki bir topusers widget'i icin de olabilirdi.

hesaplamasi 1 saniye suren, ciddi JOIN'lerin oldugu bir SQL sorgusu da olabilirdi.

halbuki, timeout vermeseydik, cache invalidation'i tembellik etmeyip kendimiz yapsaydik boyle bir problem olmayacakti.

cache'lediginiz objeler guncel olmayan bir duruma geldiginde (editorlerden biri yaziyi update etti) siz de otomatik olarak bir sinyalle objenin cache'inin uzerine yazacaksiniz. dolayisiyla, olabildiginca timeout kullanmaktan kacinip, DELETE kullanmadiginiz surece herhangi bir "cache miss" ile karsilasmayacaksiniz. yukaridaki kodu buna gore update edip biraz duzeltelim.

from django.core import cache

def get_post_data(post_id):
    cache_key = "post_{post_id}".format(post_id=post_id)

    post = cache.get(cache_key)

    if not post:
        post = Post.objects.get(pk=post_id)
        cache.set(cache_key, post)

    return post

yeni yaklasimla -teoride- hicbir sekilde cache miss ile karsilasmamamiz gerekiyor, ama yine de if not post: kismini her ihtimale karsi tutuyoruz.

problem #2: hatali URL'ler

asthon kutcher projenizi gordu, twitter'ina atti, atarken bir yanlislik oldu, URL degisti. aslinda olmayan bir yaziya milyonlar twitterdan geldi. yukaridaki kodta, aslinda olmayan bir yazi icin onlarca cache ve db sorgusu demek. buradaki yuku azaltmak da mumkun.

from django.core import cache

NOT_FOUND = "404"

def get_post_data(post_id):
    cache_key = "post_{post_id}".format(post_id=post_id)

    post = cache.get(cache_key)

    if post == NOT_FOUND:
        raise Post.DoesNotExist

    if not post:
        try:
            post = Post.objects.get(pk=post_id)                
        except Post.DoesNotExist:
            post = NOT_FOUND

        cache.set(cache_key, post)        

    return post

1 sefer baktik database'e. eger boyle bir sey yoksa, belirledigimiz "icerik bulunamadi" kodunu cache key'ine atadik. ilk istekten sonra gelen tum istekler icin bundan sonra db'ye gidilmeyecek. aslinda bulunamayan yaziya post girilse dahi, key update edilecegi icin herhangi bir sikinti olmayacak.

iyilestirme #1: global bir cache_key listesi

buyuk projelerde onlarca belki de yuzlerce cache key'i olabilir. dolayisiyla cache key'lerini bunun gibi bir fonksiyon icerisinde hazirlamak yerine, cache_keys.py gibi ayri bir dosya tutmak ve gerektiginde import edip kullanmak daha mantikli.

su sekilde ayri bir dosyaniz oldugunu dusunun:

cache_keys.py

NOT_FOUND = "404"

keys = {
    "post": "post_{post_id}",
    "comment": "comment_{comment_id}",
}

daha sonra view dosyanizda bunu kullanmak kolay:

>>> import cache_keys
>>> cache_keys.keys["post"].format(post_id=42)
post_42

bu sekilde kullanmak insani hatalardan dolayi farkli key'lerle ugrasmanizi engeller, projeye sonradan katilan dev. icin de harika bir sey olur.

from django.core import cache
from cache_keys import keys
from cache_keys import NOT_FOUND

def get_post_data(post_id):
    cache_key = cache_keys.keys["post"].format(post_id=post_id)

    post = cache.get(cache_key)

    if post == NOT_FOUND:
        raise Post.DoesNotExist

    if not post:
        try:
            post = Post.objects.get(pk=post_id)
        except Post.DoesNotExist:
            post = NOT_FOUND

        cache.set(cache_key, post)        

    return post

kod ilk haline gore oldukca degisti. ama cok daha saglam.

--

genel oneriler

• modellerin save/update gibi metodlarinda cache set/update gibi isler yapmayin. django icin model signals ile halledin ornegin.
• birden fazla makineyi caching olarak kullaniyorsaniz consistent hashing kullanin. data invalidation oranini server ekleme/cikarma gibi durumlarda minimuma indirip guzel bir dagitim orani saglayacaktir.
• memcache, redis gibi gibi sistemlerin portlari disariya acik olmamali. maalesef cok gozardi edilen bir durum.
• in process caching/memoization kullanin. django orm'in bir cok durumda lazy sorgular atmasi buna guzel bir ornek.
• varnish gibi upstream caching sistemleri az maliyetli ve cok etkili. kullanilabilecek yerlerde kullanmak cok mantikli.
• caching'e gercekten ihtiyaciniz var mi emin olun. kodunuzu gereksiz yere karmasik hale getirmeniz her zaman gerekli olmayabilir.