Burada ne görüyorsunuz

İki yüz cache key’i — session’lar, sepetler, ürün ID’leri — 32 bitlik hash uzayını temsil eden bir çembere hash’leniyor. Request’ler merkezden çıkıyor, key’ini buluyor ve o key’in sahibi olan cache node’una gidiyor. Yan panel production’da önemli olanı sayıyor: cluster değiştiğinde kaç key’in sahibi değişiyor, yük ne kadar eşit dağılıyor ve cache hit oranı ne durumda — çünkü yer değiştiren her key, veritabanına düşen bir miss demek.

hash % N neden can yakar

hash(key) % N key’leri iyi dağıtır ama N formülün bir parçası: dört node’dan beşe çıktığınızda kabaca her beş key’den dördü başka bir node’a düşer. Bir cache için bu, ani bir miss dalgası demek — arkadaki sisteme kendi elinizle yolladığınız bir thundering herd. “Yer değiştiren” çubukları her değişikliği üç eşlemede birden hesaplıyor; böylece hepsini tam olarak aynı olay üzerinden kıyaslayabiliyorsunuz.

Halkalar ve sanal node’lar

Consistent hashing, node’ları key’lerle aynı halkaya koyar; bir key saat yönündeki ilk node’a aittir. Yeni bir node sadece kendinden hemen önceki yayı devralır, yani key’lerin yaklaşık 1/N’i taşınır — teorik minimum bu. Ama node başına tek nokta olunca yay uzunlukları rastgeledir ve bir node payından çok daha fazlasına sahip olabilir. Sanal node’lar her sunucuya halkada çok sayıda nokta verir; yük dengelenir ve çıkarılan bir node’un key’leri tek bir komşuya yığılmak yerine kalan herkese dağılır. Dynamo tarzı veri depolarının, Cassandra token aralıklarının ve çoğu memcached client kütüphanesinin arkasındaki fikir bu.

Hashing’in çözemediği şey tek bir ünlü key: halkayı nasıl bölerseniz bölün, bir key’in bütün request’leri tek bir node’a gider. Bunun için başka bir araç gerekir — sıcak key’leri replike etmek, önüne küçük bir lokal cache koymak ya da key’in kendisini bölmek.