Как ние от Спортмастер избрахме система за кеширане. Част 1

Здравейте! Казвам се Алексей Пянков, разработчик съм във фирма Спортмастер. В това пост Разказах как започна работата по уебсайта Sportmaster през 2012 г., какви инициативи успяхме да „прокараме“ и обратно, какъв рейк събрахме.

Днес искам да споделя мисли, които следват друга тема - избор на система за кеширане за бекенда на Java в административната област на сайта. За мен този сюжет има особено значение – въпреки че историята се развиваше само 2 месеца, през тези 60 дни работихме по 12-16 часа и без нито един почивен ден. Никога не бях мислил или предполагал, че е възможно да работя толкова много.

Затова разделих текста на 2 части, за да не го натоварвам изцяло. Напротив, първата част ще бъде много лека - подготовка, въведение, някои съображения за това какво е кеширане. Ако вече сте опитен разработчик или сте работили с кешове, от техническа страна най-вероятно няма да има нищо ново в тази статия. Но за младши такъв малък преглед може да му подскаже в коя посока да гледа, ако се окаже на такъв кръстопът.

При пускането в производство на новата версия на сайта Спортмастер данните бяха получени по меко казано неудобен начин. Основата бяха таблици, подготвени за предишната версия на сайта (Bitrix), които трябваше да бъдат изтеглени в ETL, приведени в нова форма и обогатени с различни малки неща от още дузина системи. За да се появи нова снимка или описание на продукта в сайта, трябваше да изчакате до следващия ден - актуализации само през нощта, веднъж на ден.

Отначало имаше толкова много притеснения от първите седмици от пускането в производство, че подобни неудобства за мениджърите на съдържание бяха дреболия. Но веднага след като всичко се уреди, развитието на проекта продължи - няколко месеца по-късно, в началото на 2015 г., започнахме активно да развиваме админ панела. През 2015 и 2016 г. всичко върви добре, пускаме редовно, административният панел обхваща все по-голяма част от подготовката на данните и се подготвяме за това, че скоро на нашия екип ще бъде поверено най-важното и сложно нещо - продукта верига (пълна подготовка и поддръжка на данни за всички продукти). Но през лятото на 2017 г., точно преди стартирането на стоковата верига, проектът ще се окаже в много трудна ситуация - именно поради проблеми с кеширането. Искам да говоря за този епизод във втората част на тази публикация в две части.

Но в тази публикация ще започна отдалеч, ще представя някои мисли - идеи за кеширане, което би било добра стъпка за превъртане преди голям проект.

Когато възникне задача за кеширане

Задачата за кеширане не се появява просто. Ние сме разработчици, пишем софтуерен продукт и искаме той да бъде търсен. Ако продуктът е търсен и успешен, потребителите ще дойдат. И идват още и още. И тогава има много потребители и тогава продуктът става силно натоварен.

На първите етапи не мислим за оптимизация и производителност на кода. Основното е функционалността, бързото пускане на пилот и тестване на хипотези. И ако натоварването се увеличи, изпомпваме желязото. Увеличаваме го два или три пъти, пет пъти, може би 10 пъти. Някъде тук – финансите вече не го позволяват. Колко пъти ще се увеличи броят на потребителите? Няма да е като 2-5-10, но ако успее, ще бъде от 100-1000 до 100 хиляди пъти. Тоест рано или късно ще трябва да направите оптимизация.

Да кажем, че някаква част от кода (да наречем тази част функция) отнема неприлично дълго време и искаме да намалим времето за изпълнение. Една функция може да бъде достъп до база данни или може да бъде изпълнението на някаква сложна логика - основното е, че отнема много време за изпълнение. Колко можете да намалите времето за изпълнение? В лимита можете да го намалите до нула, не повече. Как можете да намалите времето за изпълнение до нула? Отговор: напълно премахване на изпълнението. Вместо това незабавно върнете резултата. Как можете да разберете резултата? Отговор: или го изчисли, или потърси някъде. Изчисляването отнема много време. А да шпионираш означава например да запомниш резултата, който функцията е произвела последния път, когато е извикана със същите параметри.

Тоест изпълнението на функцията не е важно за нас. Достатъчно е просто да знаете от какви параметри зависи резултатът. След това, ако стойностите на параметрите са представени под формата на обект, който може да се използва като ключ в някакво хранилище, тогава резултатът от изчислението може да бъде запазен и прочетен при следващия достъп до него. Ако това писане и четене на резултата е по-бързо от изпълнението на функцията, имаме печалба по отношение на скоростта. Размерът на печалбата може да достигне 100, 1000 и 100 хиляди пъти (10^5 е по-скоро изключение, но в случай на доста изоставаща база е напълно възможно).

Основни изисквания за кешираща система

Първото нещо, което може да се превърне в изискване за кешираща система, е висока скорост на четене и, в малко по-малка степен, скорост на запис. Това е вярно, но само докато не пуснем системата в производство.

Нека изиграем този случай.

Да кажем, че сме осигурили текущото натоварване с хардуер и сега постепенно въвеждаме кеширане. Броят на потребителите расте малко, натоварването расте - добавяме малко кешове, завинтваме го тук и там. Това продължава известно време и сега тежките функции практически вече не се извикват - цялото основно натоварване пада върху кеша. Броят на потребителите през това време се е увеличил N пъти.

И ако първоначалната доставка на хардуер може да бъде 2-5 пъти, тогава с помощта на кеша бихме могли да подобрим производителността с фактор 10 или, в добрия случай, с фактор 100, на някои места може би с фактор от 1000. Тоест на същия хардуер – обработваме 100 пъти повече заявки. Страхотно, заслужавате меденките!

Но сега, в един прекрасен момент, случайно системата се срина и кешът се срина. Нищо особено - в края на краищата кешът е избран въз основа на изискването „висока скорост на четене и запис, останалото няма значение“.

Спрямо началното натоварване железният ни резерв беше 2-5 пъти, а натоварването през това време се увеличи 10-100 пъти. Използвайки кеша, елиминирахме повикванията за тежки функции и следователно всичко работи. И сега, без кеш, колко пъти ще се забави системата ни? Какво ще стане с нас? Системата ще падне.

Дори ако нашият кеш не се е сринал, а е бил изчистен само за известно време, той ще трябва да се загрее и това ще отнеме известно време. И през това време основната тежест ще падне върху функционалността.

Заключение: силно натоварените производствени проекти изискват система за кеширане не само за висока скорост на четене и запис, но и за осигуряване на безопасност на данните и устойчивост на повреди.

Брашно по избор

В проект с админ панел изборът стана така: първо инсталирахме Hazelcast, т.к Вече бяхме запознати с този продукт от опита на основния сайт. Но тук този избор се оказа неуспешен - при нашия профил на натоварване Hazelcast не е просто бавен, а ужасно бавен. И по това време вече се бяхме записали за датата на издаване.

Спойлер: как точно се стекоха обстоятелствата, че пропуснахме толкова голяма работа и се оказахме в остра и напрегната ситуация - ще ви разкажа във втората част - и как се оказахме и как се измъкнахме. Но сега - просто ще кажа, че беше много стрес и "да мисля - някак си не мога да мисля, ние разклащаме бутилката." „Разклащане на бутилката“ също е спойлер, повече за това по-късно.

Какво направихме:

1. Ние правим списък на всички системи, които Google и StackOverflow предлагат. Малко над 30
2. Пишем тестове с типично за производството натоварване. За да направим това, записахме данни, които преминават през системата в производствена среда - един вид снифър за данни не в мрежата, а вътре в системата. Точно тези данни са използвани в тестовете.
3. С целия екип всеки избира следващата система от списъка, конфигурира я и провежда тестове. Не издържа теста, не носи товара – изхвърляме го и преминаваме към следващия по ред.
4. На 17-та система стана ясно, че всичко е безнадеждно. Спрете да разклащате бутилката, време е да помислите сериозно.

Но това е опция, когато трябва да изберете система, която ще „премине скоростта“ в предварително подготвени тестове. Ами ако все още няма такива тестове и искате да изберете бързо?

Нека моделираме тази опция (трудно е да си представим, че средно+ разработчик живее във вакуум и към момента на избора все още не е формализирал предпочитанията си кой продукт да опита първо - следователно по-нататъшните разсъждения са по-скоро теоретик/философия/ за младши).

След като решихме изискванията, нека започнем да избираме решение от кутията. Защо да изобретяваме колелото: ще отидем и ще вземем готова система за кеширане.

Ако тепърва започвате и го търсите в Google, тогава дайте или вземете поръчката, но като цяло насоките ще бъдат такива. Първо ще попаднете на Redis, чува се навсякъде. Тогава ще разберете, че EhCache е най-старата и доказана система. След това ще пишем за Tarantool, местна разработка, която има уникален аспект на решението. А също и Ignite, защото сега е във възход на популярност и се радва на подкрепата на SberTech. Накрая има и Hazelcast, тъй като в корпоративния свят често се появява сред големите компании.

Списъкът не е изчерпателен; има десетки системи. И ще прецакаме само едно нещо. Нека вземем избраните 5 системи за „конкурса за красота“ и да направим селекция. Кой ще бъде победител?

Redis

Четем какво пишат на официалния сайт.
Redis - проект с отворен код. Предлага съхранение на данни в паметта, възможност за запис на диск, автоматично разделяне, висока наличност и възстановяване от прекъсване на мрежата.

Изглежда, че всичко е наред, можете да го вземете и да го завиете - всичко, от което се нуждаете, го прави. Но просто за забавление, нека да разгледаме другите кандидати.

EhCache

EhCache - „най-широко използваният кеш за Java“ (превод на слогана от официалния уебсайт). Също така с отворен код. И тогава разбираме, че Redis не е за java, а общ и за да взаимодействате с него, ви е необходима обвивка. И EhCache ще бъде по-удобен. Какво друго обещава системата? Надеждност, доказана, пълна функционалност. Е, това е и най-често срещаното. И кешира терабайти данни.

Redis е забравен, готов съм да избера EhCache.

Но чувството за патриотизъм ме тласка да видя какво е добро в Tarantool.

Tarantool

Tarantool - отговаря на обозначението „Платформа за интегриране на данни в реално време“. Звучи много сложно, затова прочитаме страницата подробно и откриваме гръмко изявление: „Кешира 100% от данните в RAM.“ Това би трябвало да повдигне въпроси - в крайна сметка може да има много повече данни, отколкото памет. Обяснението е, че това означава, че Tarantool не изпълнява сериализация, за да запише данни на диск от паметта. Вместо това, той използва функции на ниско ниво на системата, когато паметта е просто картографирана към файлова система с много добра I/O производителност. Изобщо направиха нещо прекрасно и яко.

Нека да разгледаме реализациите: корпоративна магистрала Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Ако все още има някакви съмнения относно Tarantool, тогава случаят с внедряването в Mastercard ме довършва. Вземам Tarantool.

Но както и да е…

Ignite

…има ли още Ignite, се таксува като „изчислителна платформа в паметта... скорости в паметта върху петабайти данни“. Тук също има много предимства: разпределен кеш в паметта, най-бързото съхранение и кеш на ключ-стойност, хоризонтално мащабиране, висока наличност, стриктна цялост. Като цяло се оказва, че най-бърз е Ignite.

Внедрявания: Sberbank, American Airlines, Yahoo! Япония. И тогава разбирам, че Ignite не просто е внедрен в Сбербанк, но екипът на SberTech изпраща свои хора в самия екип на Ignite, за да усъвършенстват продукта. Това е напълно завладяващо и съм готов да взема Ignite.

Напълно неясно защо, гледам петата точка.

леска

Отивам на сайта леска, четене. И се оказва, че най-бързото решение за разпределено кеширане е Hazelcast. Той е с порядъци по-бърз от всички други решения и като цяло е лидер в областта на мрежата с данни в паметта. На този фон да вземеш нещо друго означава да не уважаваш себе си. Той също така използва резервно съхранение на данни за непрекъсната работа на клъстера без загуба на данни.

Това е всичко, готов съм да взема Hazelcast.

Сравнение

Но ако погледнете, и петимата кандидати са описани по такъв начин, че всеки от тях е най-добрият. Как да изберем? Можем да видим кой е най-популярен, да потърсим сравнения и главоболието ще изчезне.

Намираме такъв преглед, изберете нашите 5 системи.

Тук са подредени: Redis е на върха, Hazelcast е на второ място, Tarantool и Ignite набират популярност, EhCache беше и си остава същият.

Но нека да разгледаме метод на изчисление: връзки към уебсайтове, общ интерес към системата, предложения за работа - страхотно! Тоест, когато системата ми се повреди, ще кажа: „Не, надеждна е! Има много предложения за работа..." Такова просто сравнение няма да свърши работа.

Всички тези системи не са просто системи за кеширане. Те също имат много функционалност, включително когато данните не се изпомпват към клиента за обработка, а обратното: кодът, който трябва да бъде изпълнен върху данните, се премества на сървъра, изпълнява се там и резултатът се връща. И не толкова често се разглеждат като отделна система за кеширане.

Добре, нека не се отказваме, нека намерим директно сравнение на системите. Нека вземем първите две опции - Redis и Hazelcast. Ние се интересуваме от скоростта и ще ги сравним въз основа на този параметър.

Hz срещу Redis

Ние намираме това сравнение:


Синьото е Redis, червеното е Hazelcast. Hazelcast печели навсякъде и има причина за това: той е многонишков, силно оптимизиран, всяка нишка работи със собствен дял, така че няма блокиране. И Redis е еднонишков; той не се възползва от съвременните многоядрени процесори. Hazelcast има асинхронен I/O, Redis-Jedis има блокиращи сокети. В крайна сметка Hazelcast използва двоичен протокол, а Redis е ориентиран към текста, което означава, че е неефективен.

За всеки случай нека се обърнем към друг източник за сравнение. Какво ще ни покаже?

Redis срещу Hz

още сравнение:


Тук, напротив, червеното е Redis. Тоест Redis превъзхожда Hazelcast по отношение на производителността. Hazelcast спечели първото сравнение, Redis спечели второто. Точно тук обясни много точно защо Hazelcast спечели предишното сравнение.

Оказва се, че резултатът от първия всъщност е фалшифициран: Redis е взет в базовата кутия, а Hazelcast е пригоден за тестов случай. Тогава се оказва: първо, не можем да се доверим на никого, и второ, когато най-накрая изберем система, все още трябва да я конфигурираме правилно. Тези настройки включват десетки, почти стотици параметри.

Разклащане на бутилката

И мога да обясня целия процес, който направихме сега, със следната метафора: „Разклащане на бутилката“. Тоест, сега не е нужно да програмирате, сега основното е да можете да четете stackoverflow. И имам човек в екипа си, професионалист, който работи точно така в критични моменти.

Какво прави той? Той вижда счупено нещо, вижда следа на стека, взема някои думи от него (които са неговата експертиза в програмата), търси в Google, намира stackoverflow сред отговорите. Без да чете, без да се замисля, сред отговорите на въпроса, той избира нещо най-подобно на изречението „направи това и това“ (избирането на такъв отговор е негов талант, защото не винаги отговорът получава най-много харесвания), прилага , изглежда: ако нещо се е променило, тогава страхотно. Ако не се е променило, върнете го назад. И повторете стартиране-проверка-търсене. И по този интуитивен начин той гарантира, че кодът работи след известно време. Не знае защо, не знае какво е направил, не може да обясни. Но! Тази инфекция работи. И „пожарът е угасен“. Сега нека разберем какво направихме. Когато програмата работи, това е порядък по-лесно. И спестява много време.

Този метод е много добре обяснен с този пример.

Някога беше много популярно да се събира платноходка в бутилка. В същото време платноходката е голяма и крехка, а гърлото на бутилката е много тясно, невъзможно е да се натисне вътре. Как да го сглобя?

Има такъв метод, много бърз и много ефективен.

Корабът се състои от куп малки неща: пръчки, въжета, платна, лепило. Всичко това слагаме в бутилка.
Хващаме бутилката с две ръце и започваме да разклащаме. Ние я клатим и клатим. И обикновено се оказва пълен боклук, разбира се. Но понякога. Понякога се оказва, че е кораб! По-точно нещо подобно на кораб.

Показваме това нещо на някого: „Серьога, виждаш ли!?“ И наистина, отдалеч изглежда като кораб. Но това не може да бъде допуснато да продължи.

Има и друг начин. Те се използват от по-напреднали момчета, като хакери.

Поставих задача на този човек, той направи всичко и си тръгна. И вие гледате - изглежда, че е готово. И след време, когато кодът трябва да бъде финализиран, това започва заради него... Добре, че вече успя да избяга надалече. Това са момчетата, които, използвайки примера на бутилка, ще направят това: виждате, където е дъното, стъклото се огъва. И не е съвсем ясно дали е прозрачен или не. След това „хакерите“ отрязаха това дъно, вмъкнаха там кораб, след което отново залепиха дъното и сякаш така трябваше да бъде.

От гледна точка на поставяне на проблема, всичко изглежда правилно. Но като използваме корабите като пример: защо изобщо да правим този кораб, кой изобщо има нужда от него? Не предоставя никаква функционалност. Обикновено такива кораби са подаръци на много високопоставени хора, които ги поставят на рафт над тях, като някакъв символ, като знак. И ако такъв човек, ръководител на голям бизнес или високопоставен служител, как ще стои знамето на такъв хак, чийто врат е отрязан? Би било по-добре той никога да не разбере за това. И така, как в крайна сметка правят тези кораби, които могат да бъдат подарени на важен човек?

Единственото ключово място, за което наистина не можете да направите нищо, е тялото. И корпусът на кораба пасва точно във врата. Докато корабът е сглобен извън бутилката. Но това не е просто сглобяване на кораб, това е истински бижутерски занаят. Към компонентите се добавят специални лостове, които след това позволяват тяхното повдигане. Платната например се сгъват, внимателно се вкарват вътре и след това с помощта на пинсети се издърпват и повдигат много прецизно, прецизно. Резултатът е произведение на изкуството, което може да бъде подарено с чиста съвест и гордост.

И ако искаме проектът да е успешен, в екипа трябва да има поне един бижутер. Някой, който държи на качеството на продукта и взема предвид всички аспекти, без да жертва нищо, дори в моменти на стрес, когато обстоятелствата изискват да се направи спешното за сметка на важното. Всички успешни проекти, които са устойчиви, които са издържали проверката на времето, са изградени на този принцип. Има нещо много прецизно и уникално в тях, нещо, което се възползва от всички налични възможности. В примера с кораба в бутилката се разиграва фактът, че корпусът на кораба минава през гърлото.

Връщайки се към задачата за избор на нашия сървър за кеширане, как може да се приложи този метод? Предлагам тази опция за избор от всички системи, които съществуват - не разклащайте бутилката, не избирайте, а вижте какво имат по принцип, какво да търсите при избора на система.

Къде да търся тесни места

Нека се опитаме да не разклащаме бутилката, да не преминаваме през всичко, което е там едно по едно, но нека да видим какви проблеми ще възникнат, ако изведнъж, за нашата задача, сами проектираме такава система. Разбира се, ние няма да сглобяваме велосипеда, но ще използваме тази диаграма, за да ни помогне да разберем на кои точки да обърнем внимание в описанията на продуктите. Нека начертаем такава диаграма.

Ако системата е разпределена, тогава ще имаме няколко сървъра (6). Да кажем, че има четири (удобно е да ги поставите на снимката, но, разбира се, може да има колкото искате). Ако сървърите са на различни възли, това означава, че всички те изпълняват някакъв код, който е отговорен за гарантирането, че тези възли образуват клъстер и в случай на прекъсване се свързват и разпознават един друг.

Нуждаем се също от кодова логика (2), която всъщност е за кеширане. Клиентите взаимодействат с този код чрез някои API. Клиентският код (1) може да бъде или в рамките на една и съща JVM, или да има достъп до нея през мрежата. Логиката, внедрена вътре, е решението кои обекти да се оставят в кеша и кои да се изхвърлят. Използваме памет (3) за съхраняване на кеша, но ако е необходимо, можем да запазим част от данните на диск (4).

Да видим в кои части ще възникне натоварването. Всъщност всяка стрелка и всеки възел ще бъдат заредени. Първо, между клиентския код и api, ако това е мрежова комуникация, слягането може да бъде доста забележимо. Второ, в рамките на самото api - ако прекаляваме със сложната логика, можем да се сблъскаме с проблеми с процесора. И би било хубаво, ако логиката не губи време за памет. И остава взаимодействието с файловата система - в обичайната версия това е сериализиране / възстановяване и запис / четене.

Следва взаимодействие с клъстера. Най-вероятно ще бъде в същата система, но може и отделно. Тук също трябва да вземете предвид прехвърлянето на данни към него, скоростта на сериализиране на данните и взаимодействията между клъстера.

Сега, от една страна, можем да си представим „какви зъбни колела ще се въртят“ в кеш системата, когато обработваме заявки от нашия код, а от друга страна, можем да преценим какви и колко заявки ще генерира нашият код към тази система. Това е достатъчно, за да направим повече или по-малко трезвен избор - да изберем система за нашия случай на използване.

леска

Нека видим как да приложим това разлагане към нашия списък. Например Hazelcast.

За да постави/вземе данни от Hazelcast, клиентският код осъществява достъп (1) до API. Hz ви позволява да стартирате сървъра като вграден и в този случай достъпът до api е извикване на метод вътре в JVM, което може да се счита за безплатно.

За да работи логиката в (2), Hz разчита на хеша на байтовия масив на сериализирания ключ - тоест ключът ще бъде сериализиран във всеки случай. Това са неизбежни режийни разходи за Hz.
Стратегиите за изгонване се изпълняват добре, но за специални случаи можете да добавите свои собствени. Не е нужно да се притеснявате за тази част.

Съхранение (4) може да бъде свързано. Страхотен. Взаимодействието (5) за вградени може да се счита за незабавно. Обмен на данни между възлите в клъстера (6) - да, съществува. Това е инвестиция в толерантност към грешки за сметка на скорост. Функцията Hz Near-cache ви позволява да намалите цената - данните, получени от други възли в клъстера, ще бъдат кеширани.

Какво може да се направи при такива условия, за да се увеличи скоростта?

Например, за да избегнете сериализирането на ключа в (2) - прикачете друг кеш върху Hazelcast за най-горещите данни. За тази цел Sportmaster избра Кофеин.

За усукване на ниво (6), Hz предлага два типа съхранение: IMap и ReplicatedMap.


Струва си да се спомене как Hazelcast влезе в технологичния стек на Sportmaster.

През 2012 г., когато работихме по първия пилотен проект на бъдещия сайт, именно Hazelcast се оказа първата връзка, която търсачката върна. Запознанството започна „от първия път“ - бяхме пленени от факта, че само два часа по-късно, когато завинтихме Hz в системата, тя работи. И се получи добре. До края на деня бяхме завършили редица тестове и бяхме доволни. И този запас от енергия беше достатъчен, за да преодолее изненадите, които Хц поднесе с времето. Сега екипът на Sportmaster няма причина да изоставя Hazelcast.

Но такива аргументи като „първата връзка в търсачката“ и „HelloWorld беше бързо сглобен“ са, разбира се, изключение и характеристика на момента, в който е направен изборът. Истинските тестове за избраната система започват с пускането в производство и именно на този етап трябва да обърнете внимание при избора на всяка система, включително кеш. Всъщност в нашия случай можем да кажем, че избрахме Hazelcast случайно, но след това се оказа, че сме избрали правилно.

За производството, много по-важно: мониторинг, обработка на повреди на отделни възли, репликация на данни, цена на мащабиране. Тоест, струва си да обърнете внимание на задачите, които ще възникнат по време на поддръжката на системата - когато натоварването е десетки пъти по-високо от планираното, когато случайно качим нещо на грешното място, когато трябва да пуснем нова версия на кода, заменете данните и го направете незабелязано за клиентите.

За всички тези изисквания Hazelcast със сигурност отговаря на изискванията.

Следва продължение

Но Hazelcast не е панацея. През 2017 г. избрахме Hazelcast за администраторския кеш, просто въз основа на добри впечатления от минал опит. Това изигра ключова роля в една много жестока шега, заради която изпаднахме в трудна ситуация и „героично” се измъквахме от нея за 60 дни. Но повече за това в следващата част.

Междувременно... Честит нов код!

Източник: www.habr.com