Cześć! Nazywam się Alexey Pyankov, jestem programistą w firmie Sportmaster. W tym Opowiedziałem jak w 2012 roku rozpoczęły się prace nad stroną Sportmaster, jakie inicjatywy udało nam się „przeforsować” i odwrotnie, jaki rake zebraliśmy.
Dzisiaj chcę podzielić się przemyśleniami związanymi z innym tematem - wyborem systemu buforowania dla backendu Java w obszarze administracyjnym witryny. Ta fabuła ma dla mnie szczególne znaczenie – choć historia trwała tylko 2 miesiące, to w ciągu tych 60 dni pracowaliśmy po 12-16 godzin i nie było ani jednego dnia wolnego. Nigdy nie myślałem ani nie wyobrażałem sobie, że można tak ciężko pracować.
Dlatego podzieliłem tekst na 2 części, żeby nie załadować go do końca. Wręcz przeciwnie, pierwsza część będzie bardzo lekka - przygotowanie, wprowadzenie, kilka rozważań na temat tego, czym jest buforowanie. Jeśli jesteś już doświadczonym programistą lub pracowałeś z pamięciami podręcznymi, od strony technicznej najprawdopodobniej w tym artykule nie będzie nic nowego. Ale dla juniora taka mała recenzja może mu podpowiedzieć, w którym kierunku szukać, jeśli znajdzie się na takim rozdrożu.
Kiedy nowa wersja serwisu Sportmaster została wdrożona do produkcji, dane zostały odebrane w sposób, delikatnie mówiąc, niezbyt wygodny. Podstawą były tabele przygotowane dla poprzedniej wersji serwisu (Bitrix), które trzeba było wciągnąć do ETL, doprowadzić do nowej formy i wzbogacić o różne drobiazgi z kilkunastu kolejnych systemów. Aby nowe zdjęcie lub opis produktu pojawiło się na stronie trzeba było poczekać do następnego dnia - aktualizacje tylko w nocy, raz dziennie.
Na początku było tyle zmartwień od pierwszych tygodni wejścia do produkcji, że takie niedogodności dla menadżerów treści były drobnostką. Ale gdy tylko wszystko się uspokoiło, rozwój projektu był kontynuowany - kilka miesięcy później, na początku 2015 roku, zaczęliśmy aktywnie rozwijać panel administracyjny. W 2015 i 2016 roku wszystko idzie dobrze, wypuszczamy regularnie, panel administracyjny zajmuje się coraz większą częścią przygotowania danych i przygotowujemy się na to, że już niedługo naszemu zespołowi zostanie powierzona najważniejsza i najbardziej skomplikowana rzecz – produkt obwodu (pełne przygotowanie i utrzymanie danych o wszystkich produktach). Jednak latem 2017 roku, tuż przed uruchomieniem obiegu towarowego, projekt znajdzie się w bardzo trudnej sytuacji – właśnie z powodu problemów z buforowaniem. O tym epizodzie chcę opowiedzieć w drugiej części tej dwuczęściowej publikacji.
Ale w tym poście zacznę od z daleka, przedstawię kilka przemyśleń - pomysłów na temat buforowania, które byłoby dobrym krokiem do przewinięcia przed dużym projektem.
Gdy wystąpi zadanie buforowania
Zadanie buforowania nie pojawia się samo. Jesteśmy programistami, piszemy oprogramowanie i chcemy, aby było na nie zapotrzebowanie. Jeśli produkt będzie poszukiwany i odniesie sukces, użytkownicy przyjdą. I przychodzi ich coraz więcej. A potem jest wielu użytkowników i produkt staje się bardzo obciążony.
Na pierwszych etapach nie myślimy o optymalizacji i wydajności kodu. Najważniejsze jest funkcjonalność, szybkie wdrożenie pilotażu i przetestowanie hipotez. A jeśli obciążenie wzrośnie, pompujemy żelazo. Zwiększamy go dwa lub trzy razy, pięć razy, może 10 razy. Gdzieś tu – finanse już na to nie pozwalają. Ile razy zwiększy się liczba użytkowników? Nie będzie to jak 2-5-10, ale jeśli się uda, będzie to od 100-1000 do 100 tysięcy razy. Oznacza to, że prędzej czy później będziesz musiał przeprowadzić optymalizację.
Powiedzmy, że jakaś część kodu (nazwijmy tę część funkcją) zajmuje nieprzyzwoicie dużo czasu, a chcemy skrócić czas wykonania. Funkcja może polegać na dostępie do bazy danych lub wykonaniu jakiejś złożonej logiki - najważniejsze jest to, że jej wykonanie zajmuje dużo czasu. Jak bardzo możesz skrócić czas realizacji? W limicie możesz go zmniejszyć do zera, nie dalej. Jak skrócić czas wykonania do zera? Odpowiedź: całkowicie wyeliminuj wykonanie. Zamiast tego natychmiast zwróć wynik. Jak można poznać wynik? Odpowiedź: albo to oblicz, albo gdzieś poszukaj. Obliczenia zajmują dużo czasu. A szpiegować oznacza na przykład zapamiętywanie wyniku, jaki funkcja wygenerowała ostatnim razem, gdy została wywołana z tymi samymi parametrami.
Oznacza to, że realizacja funkcji nie jest dla nas ważna. Wystarczy wiedzieć, od jakich parametrów zależy wynik. Następnie, jeśli wartości parametrów są reprezentowane w postaci obiektu, który może służyć jako klucz w jakiejś pamięci, wówczas wynik obliczeń można zapisać i odczytać przy następnym dostępie. Jeśli ten zapis i odczyt wyniku jest szybszy niż wykonanie funkcji, mamy zysk pod względem szybkości. Wysokość zysku może sięgać 100, 1000 i 100 tysięcy razy (10^5 to raczej wyjątek, ale w przypadku dość opóźnionej bazy jest to całkiem możliwe).
Podstawowe wymagania dotyczące systemu buforowania
Pierwszą rzeczą, która może stać się wymaganiem dla systemu buforowania, jest duża prędkość odczytu i, w nieco mniejszym stopniu, prędkość zapisu. To prawda, ale tylko do czasu, aż wdrożymy system na produkcję.
Zagrajmy w tę sprawę.
Załóżmy, że zapewniliśmy bieżące obciążenie sprzętem i teraz stopniowo wprowadzamy buforowanie. Rośnie trochę liczba użytkowników, rośnie obciążenie - dodajemy trochę cache, wkręcamy to tu, to tam. Trwa to przez jakiś czas, a teraz ciężkie funkcje praktycznie nie są już wywoływane - całe główne obciążenie spada na pamięć podręczną. Liczba użytkowników w tym czasie wzrosła N razy.
A jeśli początkowa podaż sprzętu mogłaby być 2-5 razy większa, to przy pomocy pamięci podręcznej moglibyśmy poprawić wydajność 10-krotnie lub, w dobrym przypadku, 100-krotnie, w niektórych miejscach być może nawet współczynnikiem 1000. Czyli na tym samym sprzęcie – przetwarzamy 100 razy więcej żądań. Świetnie, zasługujesz na pierniki!
Ale teraz, w pewnym pięknym momencie, przez przypadek system się zawiesił i pamięć podręczna uległa awarii. Nic specjalnego - w końcu pamięć podręczna została wybrana w oparciu o wymaganie „wysoka prędkość odczytu i zapisu, reszta nie ma znaczenia”.
W stosunku do obciążenia początkowego nasza rezerwa żelaza wynosiła 2-5 razy, a obciążenie w tym czasie wzrosło 10-100 razy. Korzystając z pamięci podręcznej, wyeliminowaliśmy wywołania ciężkich funkcji i dlatego wszystko działało. A teraz, bez pamięci podręcznej, ile razy nasz system spowolni? Co się z nami stanie? System upadnie.
Nawet jeśli nasza pamięć podręczna nie uległa awarii, a została wyczyszczona tylko na chwilę, będzie musiała zostać rozgrzana, a to zajmie trochę czasu. W tym czasie główny ciężar spadnie na funkcjonalność.
Wniosek: mocno obciążone projekty produkcyjne wymagają od systemu buforującego nie tylko wysokich prędkości odczytu i zapisu, ale także zapewnienia bezpieczeństwa danych i odporności na awarie.
Mąka z wyboru
W projekcie z panelem administracyjnym wybór był następujący: najpierw zainstalowaliśmy Hazelcast, ponieważ Znaliśmy już ten produkt z doświadczeń strony głównej. Ale tutaj ten wybór okazał się nieudany - przy naszym profilu obciążenia Hazelcast działa nie tylko wolno, ale strasznie wolno. A już wtedy byliśmy umówieni na datę premiery.
Spoiler: jak dokładnie rozwinęły się okoliczności, że przegapiliśmy tak ważną sprawę i znaleźliśmy się w ostrej i napiętej sytuacji – opowiem w drugiej części – oraz jak to się skończyło i jak się wydostaliśmy. Ale teraz – powiem tylko, że to był duży stres i „myśleć – jakoś nie mogę myśleć, potrząsamy butelką”. „Potrząsanie butelką” to także spoiler, o czym później.
Co zrobiliśmy:
- Tworzymy listę wszystkich systemów, które sugerują Google i StackOverflow. Trochę ponad 30
- Testy piszemy z obciążeniem typowym dla produkcji. W tym celu rejestrowaliśmy dane, które przechodzą przez system w środowisku produkcyjnym – swego rodzaju sniffer danych nie w sieci, ale wewnątrz systemu. Dokładnie te dane zostały wykorzystane w testach.
- Wszyscy całym zespołem wybierają z listy kolejny system, konfigurują go i przeprowadzają testy. Nie zdaje egzaminu, nie dźwiga ciężaru – wyrzucamy go i przechodzimy do następnego w kolejce.
- W systemie 17 stało się jasne, że wszystko jest beznadziejne. Przestań potrząsać butelką, czas poważnie pomyśleć.
Jest to jednak opcja, gdy trzeba wybrać system, który „przebije się przez prędkość” we wcześniej przygotowanych testach. A co jeśli nie ma jeszcze takich testów i chcesz szybko dokonać wyboru?
Zamodelujmy tę opcję (trudno sobie wyobrazić, że programista na poziomie średnim+ żyje w próżni i w momencie selekcji nie sformalizował jeszcze swoich preferencji co do tego, który produkt wypróbować jako pierwszy - dlatego dalsze rozumowanie jest bardziej teoretykiem/filozofią/ o juniorze).
Po ustaleniu wymagań zacznijmy wybierać gotowe rozwiązanie. Po co wymyślać koło na nowo: pójdziemy i weźmiemy gotowy system buforowania.
Jeśli dopiero zaczynasz i wyszukasz w Google, to złóż lub przyjmij zamówienie, ale ogólnie wytyczne będą takie. Przede wszystkim natkniecie się na Redisa, słychać to wszędzie. Wtedy przekonasz się, że EhCache to najstarszy i najbardziej sprawdzony system. Następnie napiszemy o Tarantoolu, rodzimym rozwoju, który ma unikalny aspekt rozwiązania. A także Ignite, ponieważ cieszy się obecnie coraz większą popularnością i cieszy się wsparciem SberTech. Na końcu pozostaje jeszcze Hazelcast, gdyż w świecie przedsiębiorstw często pojawia się wśród dużych firm.
Lista nie jest wyczerpująca; istnieją dziesiątki systemów. I schrzanimy tylko jedną rzecz. Weźmy wybrane 5 systemów do „konkursu piękności” i dokonajmy selekcji. Kto będzie zwycięzcą?
Redis
Czytamy, co piszą na oficjalnej stronie internetowej.
- projekt open source. Oferuje przechowywanie danych w pamięci, możliwość zapisywania na dysku, automatyczne partycjonowanie, wysoką dostępność i odzyskiwanie po awariach sieci.
Wydaje się, że wszystko jest w porządku, można to wziąć i przykręcić - wszystko, czego potrzebujesz, robi. Ale dla zabawy, spójrzmy na innych kandydatów.
EchCache
- „najpowszechniej używana pamięć podręczna dla Javy” (tłumaczenie hasła z oficjalnej strony internetowej). Również open source. I wtedy rozumiemy, że Redis nie jest przeznaczony dla Javy, ale ogólnie i do interakcji z nim potrzebujesz opakowania. A EhCache będzie wygodniejszy. Co jeszcze obiecuje system? Niezawodność, sprawdzona, pełna funkcjonalność. Cóż, jest to również najczęstsze. I buforuje terabajty danych.
Redis został zapomniany, jestem gotowy wybrać EhCache.
Ale poczucie patriotyzmu popycha mnie do zobaczenia, co jest dobre w Tarantoolu.
Tarantol
- spełnia oznaczenie „Platforma integracji danych w czasie rzeczywistym”. Brzmi to bardzo skomplikowanie, więc czytamy stronę szczegółowo i znajdujemy głośne stwierdzenie: „Przechowuje 100% danych w pamięci RAM”. To powinno rodzić pytania – w końcu danych może być znacznie więcej niż pamięci. Wyjaśnienie jest takie, że oznacza to, że Tarantool nie uruchamia serializacji w celu zapisania danych na dysk z pamięci. Zamiast tego wykorzystuje niskopoziomowe funkcje systemu, gdy pamięć jest po prostu mapowana na system plików o bardzo dobrej wydajności we/wy. Ogólnie zrobili coś wspaniałego i fajnego.
Przyjrzyjmy się wdrożeniom: autostrada korporacyjna Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Jeśli jeszcze były jakieś wątpliwości co do Tarantoola, to sprawa wdrożeniowa w Mastercard mnie wykańcza. Biorę Tarantool.
Ale w każdym razie…
Zapalać
…czy jest tego więcej , jest reklamowana jako „platforma obliczeniowa w pamięci... z szybkością w pamięci na petabajtach danych”. Jest tu również wiele zalet: rozproszona pamięć podręczna w pamięci, najszybsze przechowywanie i pamięć podręczna typu klucz-wartość, skalowanie poziome, wysoka dostępność, ścisła integralność. Ogólnie okazuje się, że najszybszy jest Ignite.
Wdrożenia: Sberbank, American Airlines, Yahoo! Japonia. A potem dowiaduję się, że Ignite nie jest wdrażany tylko w Sberbanku, ale zespół SberTech wysyła swoich ludzi do samego zespołu Ignite, aby udoskonalić produkt. To jest całkowicie wciągające i jestem gotowy, aby wziąć Ignite.
Zupełnie nie jest jasne dlaczego, patrzę na piąty punkt.
Leszczyna
Idę do serwisu , czytanie. Okazuje się, że najszybszym rozwiązaniem do rozproszonego buforowania jest Hazelcast. Jest o rząd wielkości szybszy od wszystkich innych rozwiązań i ogólnie jest liderem w dziedzinie sieci danych in-memory. Na tym tle wzięcie czegoś innego nie jest równoznaczne z szanowaniem siebie. Wykorzystuje także redundantną pamięć danych, aby zapewnić ciągłą pracę klastra bez utraty danych.
To wszystko, jestem gotowy na przyjęcie Hazelcast.
Porównanie
Ale jeśli spojrzeć, cała piątka kandydatów jest opisana w taki sposób, że każdy z nich jest najlepszy. Jak wybrać? Zobaczymy, który jest najpopularniejszy, poszukamy porównań, a ból głowy minie.
Znajdujemy taki , wybierz nasze 5 systemów.
Oto ich sortowanie: Redis jest na szczycie, Hazelcast jest na drugim miejscu, Tarantool i Ignite zyskują na popularności, EhCache był i pozostaje taki sam.
Ale spójrzmy : linki do stron internetowych, ogólne zainteresowanie systemem, oferty pracy - świetnie! Oznacza to, że gdy mój system ulegnie awarii, powiem: „Nie, jest niezawodny! Jest wiele ofert pracy…” Takie proste porównanie nie wystarczy.
Wszystkie te systemy to nie tylko systemy buforujące. Mają także wiele funkcji, gdy dane nie są pompowane do klienta w celu przetworzenia, ale odwrotnie: kod, który należy wykonać na danych, jest przesyłany na serwer, tam jest wykonywany, a wynik jest zwracany. I nie są tak często uważane za odrębny system buforowania.
OK, nie poddawajmy się, znajdźmy bezpośrednie porównanie systemów. Weźmy dwie najlepsze opcje - Redis i Hazelcast. Nas interesuje prędkość i będziemy je porównywać na podstawie tego parametru.
Hz kontra Redis
Znajdujemy to :
Niebieski to Redis, czerwony to Hazelcast. Hazelcast wygrywa wszędzie i ma ku temu uzasadnienie: jest wielowątkowy, wysoce zoptymalizowany, każdy wątek działa z własną partycją, więc nie ma blokowania. Redis jest jednowątkowy i nie korzysta z nowoczesnych procesorów wielordzeniowych. Hazelcast ma asynchroniczne wejścia/wyjścia, Redis-Jedis ma gniazda blokujące. W końcu Hazelcast używa protokołu binarnego, a Redis koncentruje się na tekście, co oznacza, że jest nieefektywny.
Na wszelki wypadek skorzystajmy z innego źródła porównania. Co nam pokaże?
Redis kontra Hz
Inny :
Tutaj wręcz przeciwnie, czerwony to Redis. Oznacza to, że Redis przewyższa Hazelcast pod względem wydajności. Hazelcast wygrał pierwsze porównanie, Redis wygrał drugie. wyjaśnił bardzo dokładnie, dlaczego Hazelcast wygrał poprzednie porównanie.
Okazuje się, że wynik pierwszego z nich został faktycznie sfałszowany: Redis został wzięty w podstawowym pudełku, a Hazelcast został dostosowany do przypadku testowego. Potem okazuje się: po pierwsze, nikomu nie można ufać, a po drugie, kiedy już ostatecznie wybierzemy system, nadal musimy go poprawnie skonfigurować. Ustawienia te obejmują dziesiątki, prawie setki parametrów.
Potrząsanie butelką
Cały proces, który teraz przeprowadziliśmy, mogę wyjaśnić następującą metaforą: „Potrząsanie butelką”. Oznacza to, że teraz nie musisz programować, teraz najważniejsze jest, aby móc czytać przepełnienie stosu. A ja mam w swoim zespole osobę, profesjonalistę, która w krytycznych momentach tak właśnie działa.
Co on robi? Widzi zepsutą rzecz, widzi ślad stosu, bierze z tego kilka słów (które są jego specjalnością w programie), szuka w Google, znajduje wśród odpowiedzi przepełnienie stosu. Bez czytania, bez zastanowienia, spośród odpowiedzi na pytanie wybiera coś najbardziej zbliżonego do zdania „zrób to i tamto” (wybranie takiej odpowiedzi to jego talent, bo nie zawsze jest to odpowiedź, która zbiera najwięcej lajków), dotyczy, wygląda: jeśli coś się zmieniło, to świetnie. Jeśli się nie zmieniło, wycofaj to. I powtórz uruchomienie-sprawdzenie-wyszukiwanie. I w ten intuicyjny sposób dba o to, aby kod po pewnym czasie zadziałał. Nie wie dlaczego, nie wie, co zrobił, nie potrafi wyjaśnić. Ale! Ta infekcja działa. I „ogień zgasł”. Teraz zastanówmy się, co zrobiliśmy. Kiedy program działa, jest to o rząd wielkości łatwiejsze. I oszczędza mnóstwo czasu.
Metodę tę bardzo dobrze wyjaśniono na tym przykładzie.
Kiedyś bardzo popularne było kolekcjonowanie żaglówki w butelce. Jednocześnie żaglówka jest duża i delikatna, a szyjka butelki bardzo wąska, nie da się jej wepchnąć do środka. Jak to złożyć?
Istnieje taka metoda, bardzo szybka i bardzo skuteczna.
Statek składa się z kilku drobiazgów: patyków, lin, żagli, kleju. Wszystko to wlewamy do butelki.
Bierzemy butelkę obiema rękami i zaczynamy się potrząsać. Potrząsamy nią i potrząsamy nią. I zwykle okazuje się to oczywiście kompletnym śmieciem. Ale czasami. Czasem okazuje się, że to statek! Dokładniej, coś podobnego do statku.
Pokazujemy to komuś: „Seryoga, widzisz!?” I rzeczywiście, z daleka wygląda jak statek. Nie można jednak pozwolić, aby to trwało dalej.
Jest inny sposób. Używają ich bardziej zaawansowani ludzie, na przykład hakerzy.
Dałem temu gościowi zadanie, zrobił wszystko i odszedł. A ty patrzysz – wygląda na to, że gotowe. A po pewnym czasie, gdy trzeba dokończyć kod, zaczyna się to przez niego... Dobrze, że zdążył już daleko uciec. To są goście, którzy na przykładzie butelki zrobią to: widzisz, gdzie jest dno, szkło się wygina. I nie jest do końca jasne, czy jest przezroczysty, czy nie. Następnie „hakerzy” odcinają to dno, wstawiają tam statek, po czym dno ponownie przyklejają i jest tak, jakby tak miało być.
Z punktu widzenia ustawienia problemu wszystko wydaje się być prawidłowe. Ale używając statków jako przykładu: po co w ogóle budować ten statek, kto w ogóle go potrzebuje? Nie zapewnia żadnej funkcjonalności. Zwykle takie statki są prezentami dla bardzo wysokich rangą osób, które stawiają je na półce nad sobą, jako jakiś symbol, jako znak. A jeśli taka osoba, szef dużej firmy lub urzędnik wysokiego szczebla, jak flaga wytrzyma taki hack, któremu odcięto szyję? Byłoby lepiej, gdyby nigdy się o tym nie dowiedział. Jak więc powstają te statki, które można podarować ważnej osobie?
Jedynym kluczowym miejscem, z którym tak naprawdę nie można nic zrobić, jest ciało. A kadłub statku pasuje idealnie do szyi. Natomiast statek składa się poza butelką. Ale to nie tylko składanie statku, to prawdziwe rzemiosło jubilerskie. Do podzespołów dodawane są specjalne dźwignie, które następnie pozwalają na ich podniesienie. Na przykład żagle są składane, ostrożnie wkładane do środka, a następnie za pomocą pęsety są naciągane i podnoszone bardzo precyzyjnie, z precyzją. Rezultatem jest dzieło sztuki, które można obdarować z czystym sumieniem i dumą.
A jeśli chcemy, aby projekt zakończył się sukcesem, w zespole musi być przynajmniej jeden jubiler. Kogoś, kto dba o jakość produktu i bierze pod uwagę wszystkie aspekty, nie poświęcając niczego, nawet w chwilach stresu, gdy okoliczności wymagają zrobienia tego, co pilne kosztem tego, co ważne. Wszystkie udane projekty, które są zrównoważone i przetrwały próbę czasu, opierają się na tej zasadzie. Jest w nich coś bardzo precyzyjnego i niepowtarzalnego, coś, co wykorzystuje wszystkie dostępne możliwości. W przykładzie ze statkiem w butelce rozgrywa się fakt, że kadłub statku przechodzi przez szyję.
Wracając do zadania wyboru naszego serwera buforującego, jak można zastosować tę metodę? Oferuję taką możliwość wyboru spośród wszystkich istniejących systemów - nie potrząsaj butelką, nie wybieraj, ale spójrz, co w zasadzie mają, na co zwrócić uwagę przy wyborze systemu.
Gdzie szukać wąskiego gardła
Starajmy się nie potrząsać butelką, nie przeglądać po kolei wszystkiego, co tam jest, ale zobaczmy, jakie problemy się pojawią, jeśli nagle, dla naszego zadania, sami zaprojektujemy taki układ. Roweru oczywiście nie złożymy, ale dzięki temu schematowi dowiemy się, na co warto zwrócić uwagę w opisach produktów. Naszkicujmy taki diagram.
Jeśli system jest rozproszony, wówczas będziemy mieli kilka serwerów (6). Załóżmy, że są cztery (wygodnie jest umieścić je na zdjęciu, ale oczywiście może być ich tyle, ile chcesz). Jeśli serwery znajdują się w różnych węzłach, oznacza to, że na wszystkich uruchamiany jest kod odpowiedzialny za to, aby te węzły tworzyły klaster, a w przypadku awarii łączyły się i rozpoznawały.
Potrzebujemy także logiki kodu (2), która w rzeczywistości dotyczy buforowania. Klienci wchodzą w interakcję z tym kodem za pośrednictwem interfejsu API. Kod klienta (1) może znajdować się w tej samej maszynie JVM lub uzyskać do niego dostęp przez sieć. Logika zaimplementowana wewnątrz polega na decyzji, które obiekty pozostawić w pamięci podręcznej, a które wyrzucić. Do przechowywania pamięci podręcznej wykorzystujemy pamięć (3), ale w razie potrzeby część danych możemy zapisać na dysku (4).
Zobaczmy, w jakich częściach wystąpi obciążenie. Właściwie każda strzałka i każdy węzeł zostaną załadowane. Po pierwsze, pomiędzy kodem klienta a interfejsem API, jeśli jest to komunikacja sieciowa, osiadanie może być dość zauważalne. Po drugie w ramach samego API – jeśli przesadzimy ze skomplikowaną logiką, możemy natrafić na problemy z procesorem. I byłoby miło, gdyby logika nie marnowała czasu na pamięć. Pozostaje interakcja z systemem plików - w zwykłej wersji jest to serializacja/przywracanie i zapis/odczyt.
Następna jest interakcja z klastrem. Najprawdopodobniej będzie w tym samym systemie, ale może być osobno. Tutaj także trzeba wziąć pod uwagę przesyłanie do niego danych, szybkość serializacji danych oraz interakcje pomiędzy klastrem.
Teraz z jednej strony możemy sobie wyobrazić, „jakie biegi będą kręcić” w systemie cache podczas przetwarzania żądań z naszego kodu, a z drugiej strony możemy oszacować, jakie i ile żądań nasz kod wygeneruje do tego systemu. To wystarczy, aby dokonać mniej lub bardziej trzeźwego wyboru – dobrać system do naszego przypadku użycia.
Leszczyna
Zobaczmy, jak zastosować tę dekompozycję do naszej listy. Na przykład Hazelcast.
Aby umieścić/pobrać dane z Hazelcast, kod klienta uzyskuje dostęp do (1) interfejsu API. Hz pozwala na uruchomienie serwera jako wbudowanego i w tym przypadku dostęp do API to wywołanie metody wewnątrz JVM, co można uznać za bezpłatne.
Aby logika z (2) działała, Hz opiera się na haszu tablicy bajtów serializowanego klucza - to znaczy, że klucz i tak będzie serializowany. Jest to nieunikniony narzut dla Hz.
Strategie eksmisji są dobrze wdrożone, ale w szczególnych przypadkach można dodać własne. Nie musisz się martwić o tę część.
Możliwość podłączenia magazynu (4). Świetnie. Interakcję (5) dla osadzonych można uznać za natychmiastową. Wymiana danych pomiędzy węzłami w klastrze (6) - tak, istnieje. Jest to inwestycja w odporność na błędy kosztem szybkości. Funkcja Hz Near-cache pozwala obniżyć cenę – dane otrzymane z innych węzłów w klastrze będą buforowane.
Co można zrobić w takich warunkach, aby zwiększyć prędkość?
Na przykład, aby uniknąć serializacji klucza w (2) - podłącz kolejną pamięć podręczną na Hazelcast, aby uzyskać najgorętsze dane. Sportmaster wybrał do tego celu kofeinę.
Do skręcania na poziomie (6) Hz oferuje dwa typy przechowywania: IMap i ReplicatedMap.
Warto wspomnieć, jak Hazelcast dostał się do stosu technologii Sportmaster.
W 2012 roku, gdy pracowaliśmy nad pierwszym pilotażem przyszłej witryny, to właśnie Hazelcast okazał się pierwszym linkiem, który zwróciła wyszukiwarka. Znajomość zaczęła się „za pierwszym razem” – urzekł nas fakt, że już dwie godziny później, gdy wkręciliśmy Hz do systemu, zadziałało. I to zadziałało dobrze. Pod koniec dnia przeprowadziliśmy szereg testów i byliśmy zadowoleni. I ta rezerwa wigoru wystarczyła, aby przezwyciężyć niespodzianki, jakie z biegiem czasu rzucał Hz. Teraz zespół Sportmaster nie ma powodu porzucać Hazelcast.
Ale takie argumenty jak „pierwszy link w wyszukiwarce” i „HelloWorld szybko się zmontowało” to oczywiście wyjątek i cecha momentu, w którym nastąpił wybór. Prawdziwe testy wybranego systemu rozpoczynają się w momencie wypuszczenia go do produkcji i to właśnie na tym etapie należy zwrócić uwagę na wybór dowolnego systemu, łącznie z pamięcią podręczną. Właściwie w naszym przypadku można powiedzieć, że wybraliśmy Hazelcast przez przypadek, ale potem okazało się, że wybraliśmy trafnie.
Dla produkcji znacznie ważniejsze: monitorowanie, obsługa awarii na poszczególnych węzłach, replikacja danych, koszt skalowania. Czyli warto zwrócić uwagę na zadania, które pojawią się podczas konserwacji systemu - gdy obciążenie będzie kilkadziesiąt razy większe niż planowano, gdy przez przypadek wgramy coś w złym miejscu, gdy będziemy musieli wgrać nową wersję kodu, podmień dane i zrób to niezauważalnie dla klientów.
W przypadku wszystkich tych wymagań Hazelcast z pewnością spełnia wymagania.
Ciąg dalszy nastąpi
Ale Hazelcast nie jest panaceum. W 2017 roku wybraliśmy Hazelcast do pamięci podręcznej administratora, po prostu w oparciu o dobre wrażenia z poprzednich doświadczeń. Odegrało to kluczową rolę w bardzo okrutnym dowcipie, przez który znaleźliśmy się w trudnej sytuacji i „bohatersko” wydostaliśmy się z niej na 60 dni. Ale o tym w następnej części.
W międzyczasie... Szczęśliwego Nowego Kodu!
Źródło: www.habr.com