Merhaba! Adım Alexey Pyankov, Sportmaster şirketinde geliştiriciyim. Şöyle Sportmaster web sitesindeki çalışmaların 2012'de nasıl başladığını, hangi girişimleri "başarmayı" başardığımızı ve bunun tersini, hangi komisyonları topladığımızı anlattım.
Bugün başka bir konuyu takip eden düşüncelerimi paylaşmak istiyorum - site yönetimi alanında Java arka ucu için bir önbellekleme sistemi seçmek. Bu olay örgüsünün benim için özel bir anlamı var; hikaye sadece 2 ay sürse de, bu 60 gün boyunca bir gün bile izinsiz, 12-16 saat çalıştık. Bu kadar çok çalışmanın mümkün olabileceğini hiç düşünmemiştim ve hayal etmemiştim.
Bu nedenle metni tamamen yüklememek için 2 parçaya böldüm. Tam tersine, ilk bölüm çok hafif olacak; hazırlık, giriş ve önbelleğe almanın ne olduğuna dair bazı düşünceler. Zaten deneyimli bir geliştiriciyseniz veya önbelleklerle çalıştıysanız, teknik açıdan bu makalede büyük olasılıkla yeni bir şey olmayacaktır. Ancak bir genç için bu kadar küçük bir inceleme, kendisini böyle bir yol ayrımında bulursa hangi yöne bakması gerektiğini söyleyebilir.
Sportmaster web sitesinin yeni versiyonu yayına alındığında veriler, en hafif deyimle pek de uygun olmayan bir şekilde alındı. Temel, sitenin önceki sürümü (Bitrix) için hazırlanan, ETL'ye çekilmesi, yeni bir forma getirilmesi ve bir düzine sistemden çeşitli küçük şeylerle zenginleştirilmesi gereken tablolardı. Yeni bir resmin veya ürün açıklamasının sitede görünmesi için ertesi güne kadar beklemeniz gerekiyordu - güncellemeler yalnızca geceleri, günde bir kez.
İlk başta, üretime geçmenin ilk haftalarından itibaren o kadar çok endişe vardı ki, içerik yöneticileri için bu tür rahatsızlıklar önemsizdi. Ancak her şey düzeldiğinde projenin gelişimi devam etti - birkaç ay sonra, 2015'in başında yönetici panelini aktif olarak geliştirmeye başladık. 2015 ve 2016'da her şey yolunda gidiyor, düzenli olarak yayınlıyoruz, yönetici paneli veri hazırlığının giderek daha fazlasını kapsıyor ve yakında ekibimize en önemli ve karmaşık şeyin - ürün - görevlendirileceği gerçeğine hazırlanıyoruz. devre (tüm ürünlerdeki verilerin tam olarak hazırlanması ve bakımı). Ancak 2017 yazında, ürün devresinin başlatılmasından hemen önce proje kendisini tam da önbellekleme sorunları nedeniyle çok zor bir durumda bulacak. İki bölümlük bu yayının ikinci bölümünde bu bölümden bahsetmek istiyorum.
Ancak bu yazıya uzaktan başlayacağım, önbelleğe alma hakkında bazı düşünceler - fikirler sunacağım; bu, büyük bir projeden önce göz atmak için iyi bir adım olabilir.
Bir önbelleğe alma görevi gerçekleştiğinde
Önbelleğe alma görevi sadece görünmüyor. Biz geliştiriciyiz, bir yazılım ürünü yazıyoruz ve onun talep görmesini istiyoruz. Ürün talep görüyorsa ve başarılıysa kullanıcılar gelecektir. Ve giderek daha fazlası geliyor. Ve sonra çok sayıda kullanıcı var ve ürün oldukça yüklü hale geliyor.
İlk aşamalarda optimizasyon ve kod performansını düşünmüyoruz. Önemli olan işlevsellik, hızlı bir şekilde pilot uygulama ve hipotezlerin test edilmesidir. Yük artarsa ütüyü pompalarız. İki üç kat, beş kat, belki 10 kat artırıyoruz. Burada bir yerlerde, finans artık buna izin vermiyor. Kullanıcı sayısı kaç kat artacak? 2-5-10 gibi olmayacak ama başarılı olursa 100-1000'den 100 bin katına kadar çıkacak. Yani er ya da geç optimizasyon yapmanız gerekecek.
Diyelim ki kodun bir kısmı (bu kısma fonksiyon diyelim) aşırı derecede uzun sürüyor ve yürütme süresini kısaltmak istiyoruz. Bir işlev bir veritabanına erişim olabilir veya bazı karmaşık mantığın yürütülmesi olabilir; asıl mesele, tamamlanmasının uzun zaman almasıdır. Yürütme süresini ne kadar azaltabilirsiniz? Limitte onu sıfıra düşürebilirsiniz, daha fazla değil. Yürütme süresini nasıl sıfıra düşürebilirsiniz? Cevap: Yürütmeyi tamamen ortadan kaldırın. Bunun yerine sonucu hemen döndürün. Sonucu nasıl öğrenebilirsiniz? Cevap: Ya hesaplayın ya da bir yere bakın. Hesaplamak uzun zaman alıyor. Ve casusluk yapmak, örneğin, aynı parametrelerle çağrıldığında fonksiyonun son kez ürettiği sonucu hatırlamaktır.
Yani fonksiyonun uygulanması bizim için önemli değil. Sonucun hangi parametrelere bağlı olduğunu bilmek yeterlidir. Daha sonra, parametre değerleri bazı depolarda anahtar olarak kullanılabilecek bir nesne biçiminde temsil edilirse, hesaplamanın sonucu kaydedilebilir ve bir sonraki erişimde okunabilir. Bu sonucun yazılması ve okunması fonksiyonun yürütülmesinden daha hızlı olursa hız açısından bir kazanç elde etmiş oluruz. Kâr miktarı 100, 1000 ve 100 bin katına ulaşabilir (10^5 bir istisnadır, ancak oldukça gecikmiş bir taban durumunda bu oldukça mümkündür).
Önbellekleme sistemi için temel gereksinimler
Bir önbellekleme sistemi için gereklilik haline gelebilecek ilk şey, yüksek okuma hızı ve biraz daha az bir ölçüde yazma hızıdır. Bu doğrudur, ancak yalnızca sistemi üretime çıkarana kadar.
Hadi bu davayı oynayalım.
Diyelim ki mevcut yükü donanımla sağladık ve artık yavaş yavaş önbelleğe almayı devreye sokuyoruz. Kullanıcı sayısı biraz artıyor, yük artıyor - biraz önbellek ekliyoruz, oraya buraya vidalıyoruz. Bu bir süre devam ediyor ve artık ağır işlevler pratikte çağrılmıyor - ana yükün tamamı önbelleğe düşüyor. Bu süre zarfında kullanıcı sayısı N kat arttı.
Ve eğer başlangıçtaki donanım tedariği 2-5 kat daha fazlaysa, o zaman önbellek yardımıyla performansı 10 kat veya iyi bir durumda 100 kat, bazı yerlerde belki bir kat artırabiliriz. 1000. Yani aynı donanım üzerinde 100 kat daha fazla isteği işliyoruz. Harika, zencefilli kurabiyeyi hak ettin!
Ama şimdi, bir anda şans eseri sistem çöktü ve önbellek çöktü. Özel bir şey yok - sonuçta önbellek "yüksek okuma ve yazma hızı, gerisi önemli değil" gereksinimine göre seçildi.
Başlangıç yüküne göre demir rezervimiz 2-5 kattı ve bu süre zarfındaki yük 10-100 kat arttı. Önbelleği kullanarak ağır işlev çağrılarını ortadan kaldırdık ve bu nedenle her şey işe yaradı. Peki şimdi önbellek olmadan sistemimiz kaç kez yavaşlayacak? Bize ne olacak? Sistem düşecek.
Önbelleğimiz çökmese ve yalnızca bir süreliğine temizlenmiş olsa bile ısıtılması gerekecek ve bu biraz zaman alacak. Ve bu süre zarfında asıl yük işlevsellik üzerine düşecektir.
Sonuç: Yüksek yüklü üretim projeleri, yalnızca yüksek okuma ve yazma hızlarına sahip olmak için değil, aynı zamanda veri güvenliği ve arızalara karşı dayanıklılık sağlamak için de bir önbellekleme sistemi gerektirir.
Seçim ızdırabı
Yönetici panelli bir projede seçim şu şekilde oldu: ilk önce Hazelcast'i kurduk çünkü Bu ürüne ana sitedeki deneyimlerimizden zaten aşinaydık. Ancak burada bu seçimin başarısız olduğu ortaya çıktı - yük profilimize göre Hazelcast sadece yavaş değil, aynı zamanda çok yavaş. Ve o sırada çıkış tarihi için zaten kaydolmuştuk.
Spoiler: Bu kadar büyük bir olayı kaçırdığımız, akut ve gergin bir durumla karşı karşıya kaldığımız koşullar tam olarak nasıl gelişti - ikinci bölümde anlatacağım - ve nasıl sonuçlandık ve nasıl çıktık. Ama şimdi - bunun çok fazla stres olduğunu söyleyeceğim ve "düşünmek - bir şekilde düşünemiyorum, şişeyi sallıyoruz." "Şişeyi sallamak" da spoiler niteliğindedir, buna daha sonra değineceğim.
Yaptığımız:
- Google ve StackOverflow'un önerdiği tüm sistemlerin bir listesini yapıyoruz. 30'un biraz üzerinde
- Üretim için tipik bir yükle testler yazıyoruz. Bunu yapmak için, sistemden geçen verileri bir üretim ortamında kaydettik - ağdaki değil sistem içindeki veriler için bir tür algılayıcı. Testlerde tam olarak bu veriler kullanıldı.
- Tüm ekiple birlikte herkes listeden bir sonraki sistemi seçer, yapılandırır ve testler gerçekleştirir. Testi geçemiyor, yükü taşımıyor; onu atıyoruz ve sıradakine geçiyoruz.
- 17. sistemde her şeyin umutsuz olduğu ortaya çıktı. Şişeyi sallamayı bırakın, ciddi düşünmenin zamanı geldi.
Ancak önceden hazırlanmış testlerde "hızı aşacak" bir sistem seçmeniz gerektiğinde bu bir seçenektir. Peki ya henüz böyle bir test yoksa ve hızlı bir şekilde seçim yapmak istiyorsanız?
Bu seçeneği modelleyelim (orta+ bir geliştiricinin boşlukta yaşadığını ve seçim sırasında ilk önce hangi ürünü deneyeceğine ilişkin tercihini henüz resmileştirmediğini hayal etmek zordur - bu nedenle, daha fazla akıl yürütme daha çok bir teorisyen/felsefe/ bir genç hakkında).
Gereksinimlere karar verdikten sonra kutudan çıkan bir çözümü seçmeye başlayacağız. Neden tekerleği yeniden icat edelim: gidip hazır bir önbellekleme sistemi alacağız.
Yeni başlıyorsanız ve Google'da araştırıyorsanız, o zaman siparişi verin veya alın, ancak genel olarak yönergeler bu şekilde olacaktır. Öncelikle Redis'e rastlayacaksınız, her yerde duyuluyor. O zaman EhCache'in en eski ve kanıtlanmış sistem olduğunu öğreneceksiniz. Daha sonra, çözümün benzersiz bir yönüne sahip yerli bir gelişme olan Tarantool hakkında yazacağız. Ayrıca Ignite'ın da popülaritesi artıyor ve SberTech'in desteğini alıyor. Sonunda bir de Hazelcast var, çünkü kurumsal dünyada genellikle büyük şirketler arasında karşımıza çıkıyor.
Liste kapsamlı değil; düzinelerce sistem var. Ve biz sadece tek bir şeyi mahvedeceğiz. “Güzellik yarışması” için seçilen 5 sistemi ele alalım ve bir seçim yapalım. Kazanan kim olacak?
Redis
Resmi sitede yazdıklarını okuyoruz.
- açık kaynaklı proje. Bellek içi veri depolama, diske kaydetme yeteneği, otomatik bölümleme, yüksek kullanılabilirlik ve ağ kesintilerinden kurtarma olanağı sunar.
Görünüşe göre her şey yolunda, onu alıp berbat edebilirsin - ihtiyacın olan her şey öyle. Ama sırf eğlence olsun diye diğer adaylara bakalım.
EhÖnbellek
- “Java için en yaygın kullanılan önbellek” (sloganın resmi web sitesinden çevirisi). Ayrıca açık kaynak. Ve sonra Redis'in Java için değil genel olduğunu ve onunla etkileşim kurmak için bir sarmalayıcıya ihtiyacınız olduğunu anlıyoruz. Ve EhCache daha kullanışlı olacaktır. Sistem başka ne vaat ediyor? Güvenilirlik, kanıtlanmış, tam işlevsellik. Aynı zamanda en yaygın olanıdır. Ve terabaytlarca veriyi önbelleğe alır.
Redis unutuldu, EhCache'i seçmeye hazırım.
Ancak vatanseverlik duygusu beni Tarantool'un neyin iyi olduğunu görmeye itiyor.
tarantool
- “Gerçek zamanlı veri entegrasyon platformu” tanımına uygundur. Kulağa çok karmaşık geliyor, bu yüzden sayfayı ayrıntılı olarak okuduk ve yüksek sesli bir ifadeyle karşılaştık: "Verilerin %100'ünü RAM'de önbelleğe alır." Bu durum bazı soruları gündeme getirmelidir; sonuçta hafızadan çok daha fazla veri olabilir. Bunun açıklaması, Tarantool'un bellekten diske veri yazmak için serileştirmeyi çalıştırmadığı anlamına gelmesidir. Bunun yerine, bellek çok iyi G/Ç performansına sahip bir dosya sistemiyle eşlendiğinde sistemin düşük düzeyli özelliklerini kullanır. Genel olarak harika ve harika bir şey yaptılar.
Uygulamalara bakalım: Mail.ru kurumsal otoyol, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Tarantool hakkında hâlâ şüpheler varsa Mastercard'daki uygulama işime son verir. Tarantool'u alıyorum.
Ama yine de…
Tutuşturmak
…başka var mı , "bellek içi bilgi işlem platformu... petabaytlarca veri üzerinde bellek içi hızlar" olarak faturalandırılıyor. Burada ayrıca birçok avantaj vardır: dağıtılmış bellek içi önbellek, en hızlı anahtar/değer depolama ve önbellek, yatay ölçeklendirme, yüksek kullanılabilirlik, sıkı bütünlük. Genel olarak en hızlının Ignite olduğu ortaya çıkıyor.
Uygulamalar: Sberbank, American Airlines, Yahoo! Japonya. Ve sonra Ignite'ın sadece Sberbank'ta uygulanmadığını, aynı zamanda SberTech ekibinin, ürünü geliştirmek için çalışanlarını Ignite ekibine gönderdiğini öğrendim. Bu tamamen büyüleyici ve Ignite almaya hazırım.
Nedeni tamamen belli değil, beşinci noktaya bakıyorum.
fındık
siteye gidiyorum , okuma. Ve dağıtılmış önbellekleme için en hızlı çözümün Hazelcast olduğu ortaya çıktı. Diğer tüm çözümlerden çok daha hızlıdır ve genel olarak bellek içi veri ızgarası alanında liderdir. Bu arka plana karşı, başka bir şeyi almak kendinize saygı duymamak anlamına gelir. Ayrıca kümenin veri kaybı olmadan sürekli çalışması için yedekli veri depolamayı kullanır.
İşte bu, Hazelcast'i almaya hazırım.
Karşılaştırma
Ama baktığınızda beş adayın da her biri en iyisi olacak şekilde anlatıldığını görüyorsunuz. Nasıl seçilir? Hangisinin en popüler olduğunu görebilir, karşılaştırmalara bakabiliriz ve baş ağrısı ortadan kalkacaktır.
Böyle birini buluyoruz , 5 sistemimizi seçin.
Burada sıralanıyorlar: Redis en üstte, Hazelcast ikinci sırada, Tarantool ve Ignite popülerlik kazanıyor, EhCache oldu ve aynı kalıyor.
Ama bakalım : web sitelerine bağlantılar, sisteme genel ilgi, iş teklifleri - harika! Yani sistemim arızalandığında şöyle diyeceğim: “Hayır, güvenilir! Çok sayıda iş teklifi var..." Bu kadar basit bir karşılaştırma işe yaramayacaktır.
Bu sistemlerin tümü sadece önbellekleme sistemleri değildir. Ayrıca, verilerin işlenmek üzere istemciye pompalanmaması ve bunun tersi de dahil olmak üzere birçok işlevselliğe sahiptirler: veriler üzerinde yürütülmesi gereken kod sunucuya taşınır, orada yürütülür ve sonuç döndürülür. Ve sıklıkla önbelleğe alma için ayrı bir sistem olarak görülmezler.
Tamam pes etmeyelim, sistemlerin doğrudan karşılaştırmasını bulalım. İlk iki seçeneği ele alalım - Redis ve Hazelcast. Hızla ilgileniyoruz ve bunları bu parametreye göre karşılaştıracağız.
Hz ve Redis
Bunu bulduk :
Mavi Redis'tir, kırmızı ise Hazelcast'tir. Hazelcast her yerde kazanıyor ve bunun bir mantığı var: çok iş parçacıklı, yüksek düzeyde optimize edilmiş, her iş parçacığı kendi bölümüyle çalışıyor, dolayısıyla hiçbir engelleme yok. Ve Redis tek iş parçacıklıdır; modern çok çekirdekli CPU'lardan faydalanmaz. Hazelcast'in eşzamansız G/Ç'si var, Redis-Jedis'in ise engelleme yuvaları var. Sonuçta Hazelcast ikili bir protokol kullanıyor ve Redis metin merkezli, yani verimsiz.
Her ihtimale karşı, başka bir karşılaştırma kaynağına dönelim. Bize ne gösterecek?
Redis ve Hz
Başka :
Burada tam tersine kırmızı Redis'tir. Yani Redis, performans açısından Hazelcast'ten daha iyi performans gösteriyor. İlk karşılaştırmayı Hazelcast, ikinciyi ise Redis kazandı. Hazelcast'in önceki karşılaştırmayı neden kazandığını çok net bir şekilde açıkladı.
İlkinin sonucunun aslında hileli olduğu ortaya çıktı: Redis temel kutuya alındı ve Hazelcast bir test senaryosu için tasarlandı. Sonra ortaya çıkıyor: birincisi, kimseye güvenemeyiz ve ikincisi, nihayet bir sistem seçtiğimizde, onu yine de doğru şekilde yapılandırmamız gerekiyor. Bu ayarlar onlarca, neredeyse yüzlerce parametreyi içerir.
Şişeyi sallamak
Ve şu anda yaptığımız tüm süreci şu metaforla anlatabilirim: “Şişeyi çalkalamak.” Yani artık programlamanıza gerek yok, artık asıl önemli olan yığın akışını okuyabilmektir. Ve ekibimde kritik anlarda aynen bu şekilde çalışan bir profesyonel var.
O ne yapıyor? Bozuk bir şey görüyor, bir yığın izi görüyor, ondan bazı kelimeler alıyor (hangileri programdaki uzmanlığı), Google'da arama yapıyor, cevaplar arasında yığın akışı buluyor. Okumadan, düşünmeden, sorunun cevapları arasından “şunu şunu yap” cümlesine en çok benzeyeni seçer (böyle bir cevap seçmek onun yeteneğidir, çünkü her zaman en çok beğeni alan cevap değildir), geçerlidir, görünüyor: eğer bir şey değiştiyse, o zaman harika. Eğer değişmediyse geri alın. Ve başlat-kontrol-aramayı tekrarlayın. Ve bu sezgisel yöntemle kodun bir süre sonra çalışmasını sağlar. Nedenini bilmiyor, ne yaptığını bilmiyor, açıklayamıyor. Ancak! Bu enfeksiyon işe yarıyor. Ve "yangın söndürüldü." Şimdi ne yaptığımızı bulalım. Program çalıştığında, çok daha kolaydır. Ve çok zaman kazandırır.
Bu yöntem bu örnekle çok iyi açıklanmıştır.
Bir zamanlar yelkenliyi şişede toplamak çok popülerdi. Aynı zamanda yelkenli büyük ve kırılgandır ve şişenin boynu çok dardır, onu içeri itmek imkansızdır. Nasıl monte edilir?
Böyle bir yöntem var, çok hızlı ve çok etkili.
Gemi bir sürü küçük şeyden oluşuyor: sopalar, halatlar, yelkenler, yapıştırıcı. Bütün bunları bir şişeye koyuyoruz.
Şişeyi iki elimizle alıp sallamaya başlıyoruz. Onu sallayıp sallıyoruz. Ve genellikle tamamen çöp olduğu ortaya çıkıyor elbette. Ama bazen. Bazen bir gemi olduğu ortaya çıkıyor! Daha doğrusu gemiye benzer bir şey.
Birisine şunu gösteriyoruz: “Seryoga, görüyor musun!?” Ve aslında uzaktan bir gemiye benziyor. Ancak bunun devam etmesine izin verilemez.
Başka bir yol daha var. Bilgisayar korsanları gibi daha ileri düzey kişiler tarafından kullanılırlar.
Bu adama görev verdim, her şeyi yaptı ve gitti. Ve bakıyorsun - bitmiş gibi görünüyor. Ve bir süre sonra kodun kesinleşmesi gerektiğinde bu onun yüzünden başlıyor... İyi ki çoktan kaçmayı başarmış. Bunlar, şişe örneğini kullanarak bunu yapacak olan adamlardır: görüyorsunuz, dibin olduğu yerde cam bükülüyor. Ve şeffaf olup olmadığı tam olarak belli değil. Daha sonra “hackerlar” bu tabanı kesiyor, oraya bir gemi yerleştiriyor, sonra altını tekrar yapıştırıyor ve sanki olması gereken de bu.
Sorunu belirleme açısından bakıldığında her şey doğru görünüyor. Ancak gemileri örnek olarak kullanırsak: Bu gemiyi neden yapıyoruz, buna kimin ihtiyacı var? Herhangi bir işlevsellik sağlamaz. Genellikle bu tür gemiler, onu bir tür sembol, bir işaret olarak üstlerindeki rafa koyan çok yüksek rütbeli kişilere verilen hediyelerdir. Peki böyle bir kişi, büyük bir işletmenin başı veya üst düzey bir yetkili ise boynu kesilmiş böyle bir hack'in bayrağı nasıl duracak? Bunu hiç bilmemesi daha iyi olurdu. Peki önemli bir kişiye verilebilecek bu gemileri nasıl yapıyorlar?
Hakkında hiçbir şey yapamayacağınız tek önemli yer bedeninizdir. Ve geminin gövdesi tam da boynuna sığıyor. Oysa gemi şişenin dışında monte ediliyor. Ancak bu sadece bir geminin montajı değil, gerçek bir mücevher sanatıdır. Bileşenlere, daha sonra kaldırılmalarını sağlayan özel kaldıraçlar eklenir. Mesela yelkenler katlanır, dikkatlice içeri alınır ve ardından cımbız yardımıyla çok hassas, hassas bir şekilde çekilip kaldırılır. Sonuç, temiz bir vicdan ve gururla armağan edilebilecek bir sanat eseridir.
Ve eğer projenin başarılı olmasını istiyorsak ekipte en az bir kuyumcunun olması gerekiyor. Ürünün kalitesine önem veren ve her şeyi dikkate alan, stresli anlarda, önemli olanı göze alarak acil olanı yapmayı gerektiren anlarda bile hiçbir şeyden ödün vermeden çalışan biri. Sürdürülebilir, zamana meydan okuyan tüm başarılı projeler bu prensip üzerine inşa edilmiştir. Onlarda çok kesin ve benzersiz bir şey var; mevcut tüm olasılıklardan yararlanan bir şey. Şişedeki gemi örneğinde, geminin gövdesinin boyundan geçtiği gerçeği oynanıyor.
Önbellekleme sunucumuzu seçme görevine dönersek, bu yöntem nasıl uygulanabilir? Mevcut tüm sistemlerden seçim yapma seçeneğini sunuyorum - şişeyi sallamayın, seçim yapmayın, ancak prensipte neye sahip olduklarına, bir sistem seçerken nelere dikkat etmeniz gerektiğine bakın.
Şişe boynu nerede aranmalı
Şişeyi sallamamaya, orada olan her şeyi tek tek incelememeye çalışalım ama görevimiz gereği birdenbire kendimiz böyle bir sistem tasarlarsak ne gibi sorunlar çıkacak bakalım. Elbette bisikletin montajını yapmayacağız ancak ürün açıklamalarında hangi noktalara dikkat etmemiz gerektiğini anlamamıza yardımcı olması için bu şemayı kullanacağız. Böyle bir diyagram çizelim.
Sistem dağıtılmışsa, birkaç sunucumuz olacaktır (6). Diyelim ki dört tane var (bunları resme yerleştirmek uygun ama tabii ki istediğiniz kadar da olabilir). Sunucular farklı düğümlerdeyse, bu, hepsinin bu düğümlerin bir küme oluşturmasını ve bir kesinti durumunda birbirine bağlanıp birbirini tanımasını sağlamaktan sorumlu olan bazı kodları çalıştırdığı anlamına gelir.
Ayrıca aslında önbelleğe alma ile ilgili olan kod mantığına (2) ihtiyacımız var. Müşteriler bu kodla bazı API aracılığıyla etkileşime girer. İstemci kodu (1) aynı JVM içinde olabilir veya ona ağ üzerinden erişebilir. İçeride uygulanan mantık, hangi nesnelerin önbellekte bırakılacağına ve hangilerinin atılacağına karar verilmesidir. Önbelleği depolamak için belleği (3) kullanırız, ancak gerekirse verilerin bir kısmını diske (4) kaydedebiliriz.
Bakalım yük hangi kısımlarda oluşacak. Aslında her ok ve her düğüm yüklenecek. İlk olarak, istemci kodu ile API arasında, eğer bu ağ iletişimi ise, çökme oldukça fark edilebilir. İkincisi, API'nin kendisi çerçevesinde - karmaşık mantıkla bunu abartırsak CPU ile ilgili sorunlarla karşılaşabiliriz. Ve eğer mantık hafızayla zaman kaybetmeseydi güzel olurdu. Ve dosya sistemiyle etkileşim devam ediyor - normal sürümde bu serileştirme / geri yükleme ve yazma / okumadır.
Sonraki, kümeyle etkileşimdir. Büyük olasılıkla aynı sistemde olacaktır, ancak ayrı ayrı da olabilir. Burada ayrıca veri aktarımını, veri serileştirme hızını ve küme arasındaki etkileşimleri de hesaba katmanız gerekir.
Artık bir yandan kodumuzdan gelen istekleri işlerken önbellek sisteminde “hangi dişlilerin döneceğini” hayal edebiliyoruz, diğer yandan kodumuzun bu sisteme ne ve kaç istek üreteceğini tahmin edebiliyoruz. Bu, az çok ayık bir seçim yapmak - kullanım durumumuz için bir sistem seçmek - için yeterlidir.
fındık
Bu ayrıştırmayı listemize nasıl uygulayacağımızı görelim. Örneğin Hazelcast.
Hazelcast'ten veri koymak/almak için istemci kodu API'ye erişir (1). Hz, sunucuyu gömülü olarak çalıştırmanıza olanak tanır ve bu durumda api'ye erişim, JVM içerisinde ücretsiz sayılabilecek bir yöntem çağrısıdır.
(2)'deki mantığın çalışabilmesi için Hz, serileştirilmiş anahtarın bayt dizisinin karma değerine dayanır - yani anahtar her durumda serileştirilecektir. Bu Hz.
Tahliye stratejileri iyi bir şekilde uygulanıyor ancak özel durumlar için kendinizinkini ekleyebilirsiniz. Bu kısım için endişelenmenize gerek yok.
Depolama (4) bağlanabilir. Harika. Gömülü için etkileşim (5) anlık olarak değerlendirilebilir. Kümedeki düğümler arasında veri alışverişi (6) - evet, mevcut. Bu, hız pahasına hata toleransına yapılan bir yatırımdır. Hz özelliği Yakın önbelleğe alma, fiyatı düşürmenize olanak tanır; kümedeki diğer düğümlerden alınan veriler önbelleğe alınır.
Bu gibi durumlarda hızı artırmak için ne yapılabilir?
Örneğin, (2)'deki anahtarın serileştirilmesini önlemek için, en güncel veriler için Hazelcast'in üstüne başka bir önbellek ekleyin. Sportmaster bu amaçla Kafein'i seçti.
(6) düzeyindeki büküm için Hz, iki tür depolama olanağı sunar: IMap ve ReplicatedMap.
Hazelcast'in Sportmaster teknoloji yığınına nasıl girdiğini belirtmekte fayda var.
2012 yılında, gelecekteki sitenin ilk pilotu üzerinde çalışırken, arama motorunun döndürdüğü ilk bağlantının Hazelcast olduğu ortaya çıktı. Tanışma “ilk seferde” başladı; sadece iki saat sonra Hz. Ve iyi çalıştı. Günün sonunda birçok testi tamamladık ve mutluyduk. Ve bu kuvvet rezervi, Hz. Peygamber'in zamanla ortaya çıkardığı sürprizleri aşmaya yetiyordu. Artık Sportmaster ekibinin Hazelcast'ten vazgeçmesi için hiçbir neden yok.
Ancak "arama motorundaki ilk bağlantı" ve "HelloWorld hızlı bir şekilde bir araya getirildi" gibi argümanlar elbette bir istisna ve seçimin gerçekleştiği anın bir özelliğidir. Seçilen sistemin gerçek testleri, üretime sunulmasıyla başlar ve bu aşamada, önbellek dahil herhangi bir sistemi seçerken dikkat etmeniz gerekir. Aslında bizim durumumuzda Hazelcast'i tesadüfen seçtiğimizi söyleyebiliriz ama sonradan doğru seçtiğimiz ortaya çıktı.
Üretim için ise çok daha önemli: izleme, bireysel düğümlerdeki arızaların ele alınması, veri çoğaltma, ölçeklendirme maliyeti. Yani, sistemin bakımı sırasında ortaya çıkacak görevlere dikkat etmeye değer - yük planlanandan on kat daha fazla olduğunda, yanlışlıkla yanlış yere bir şey yüklediğimizde, yeni bir sürüm çıkarmamız gerektiğinde kodun verilerini değiştirin ve bunu müşteriler için fark edilmeden yapın.
Tüm bu gereksinimler için Hazelcast kesinlikle bu amaca uyuyor.
Devam edecek
Ancak Hazelcast her derde deva değil. 2017'de yönetici önbelleği olarak geçmiş deneyimlerden edindiğimiz iyi izlenimlere dayanarak Hazelcast'i seçtik. Bu, çok acımasız bir şakada önemli bir rol oynadı, çünkü kendimizi zor bir durumda bulduk ve 60 gün boyunca "kahramanca" bu durumdan kurtulduk. Ancak bir sonraki bölümde bunun hakkında daha fazla bilgi vereceğiz.
Bu arada... Yeni Kodunuz Kutlu Olsun!
Kaynak: habr.com