Прывітанне! Мяне клічуць Аляксей П'янкоў, я распрацоўшчык у кампаніі Спортмайстар. У гэтым я распавёў, як пачыналася праца над сайтам Спортмайстар у 2012 годзе, якія ініцыятывы ўдалося «праштурхнуць» і наадварот, якія граблі мы сабралі.
Сёння я хачу падзяліцца думкамі, якія ідуць за іншым сюжэтам - выбар сістэмы кэшавання для java-бэкенда ў адмінцы сайта. Гэты сюжэт мае асаблівае значэнне для мяне - хоць гісторыя разгортвалася ўсяго 2 месяцы, але гэтыя 60 дзён мы працавалі па 12-16 гадзін і без адзінага выходнага. Ніколі раней не думаў і не ўяўляў, што можна так многа працаваць.
Таму тэкст разбіваю на 2 часткі, каб не загрузіць па поўнай. Наадварот, першая частка будзе вельмі лёгкай - падрыхтоўкай, увядзеннем, некаторымі меркаваннямі, што такое кэшаванне. Калі вы ўжо дасведчаны распрацоўшчык або працавалі з кэшамі - з тэхнічнага боку нічога новага ў гэтым артыкуле, хутчэй за ўсё, не будзе. А вось для джуніёра невялікі такі агляд можа падказаць, у які бок глядзець, апыніся ён на такім раздарожжы.
Калі новая версія сайта Спортмайстар была запушчана ў прадакшн, дадзеныя паступалі спосабам, мякка кажучы, не вельмі зручным. Асновай служылі табліцы, падрыхтаваныя для мінулай версіі сайта (Bitrix), якія трэба было зацягнуць у ETL, прывесці да новага ўвазе і ўзбагаціць рознымі рушачкамі яшчэ з дзясятка сістэм. Каб новая карцінка або апісанне тавару апынуліся на сайце, трэба было пачакаць да наступнага дня - абнаўленне толькі ноччу, 1 раз у суткі.
Спачатку было столькі клопатаў ад першых тыдняў выхаду ў прад, што такія нязручнасці кантэнт-мэнэджараў былі дробяззю. Але, як толькі ўсё ўтраслася, развіццё праекта працягнулася - праз некалькі месяцаў, у пачатку 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 працуе не проста павольна, а жудасна павольна. А пад тэрмінамі вываду ў харчаванне мы на той момант ужо падпісаліся.
Спойлер: як менавіта склаліся абставіны, што мы прапусцілі такую поўху і атрымалі вострую і напружаную сітуацыю - я раскажу ў другой частцы - і як апынуліся, і як выбраліся. Але цяпер - скажу толькі, што гэта быў моцны стрэс, і "думаць - неяк не думаецца, трасем бутэльку". «Трасем бутэльку» - гэта таксама спойлер, пра гэта крыху далей.
Што мы зрабілі:
- Складаем спіс з усіх сістэм, якія падказвае google і StackOverflow. Крыху больш за 30
- Пішам тэсты з нагрузкай, характэрнай для прадакшн. Для гэтага запісалі дадзеныя, якія праходзяць праз сістэму ў прадакшн-акружэнні - гэтакі сніфер для дадзеных не ў сеткі, але ўнутры сістэмы. У тэсты запускалі роўна гэтыя дадзеныя
- Усёй камандай, кожны выбірае наступную сістэму са спісу, настройвае, праганяе тэсты. Не праходзіць тэст, не цягне нагрузку - выкідваем, пераходзім да наступнай у чарзе.
- На 17-й сістэме стала зразумела, што ўсё безнадзейна. Хопіць «трэсці бутэльку», час сур'ёзна падумаць.
Але гэта варыянт, калі трэба абраць сістэму, якая "пралезе па хуткасці" у загадзя падрыхтаваных тэстах. А калі такіх тэстаў яшчэ няма і жадаецца абраць барзджэй?
Змадэлюем такі варыянт (складана ўявіць, што миддл+ распрацоўнік жыве ў вакууме, і на момант выбару яшчэ не аформіў перавагу, які прадукт спрабаваць у першую чаргу – таму, далейшыя развагі гэта, хутчэй за тэарэтыка/філасофія/пра джуніёра).
Вызначыўшыся з патрабаваннямі, пачнем выбіраць рашэнне са скрынкі. Навошта вынаходзіць ровар: мы пойдзем і возьмем гатовую сістэму кэшавання.
Калі вы толькі пачынаеце і будзеце гугліць, то плюс-мінус чарговасць, але ў цэлым, арыенціры будуць такія. У першую чаргу вы натыкнецеся на Redis, ён усюды на слыху. Потым даведаецеся, што есць EhCache як самая даўняя і правераная сістэма. Далей будзе напісана пра Tarantool – айчынную распрацоўку, у якой ёсць унікальны аспект рашэння. І таксама Ignite, таму што ён зараз на ўздыме папулярнасці і карыстаецца падтрымкай АшчадТэха. У канцы яшчэ Hazelcast, таму што ў enterprise-свеце ён часта мільгае ў асяроддзі буйных кампаній.
Гэтым спіс не вычэрпваецца, сістэм існуюць дзясяткі. А прыкруцім мы толькі адно. Возьмем выбраныя 5 сістэм на "конкурс прыгажосці" і правядзем адбор. Хто будзе пераможцам?
Redis
Чытэльны, што пішуць на афіцыйным сайце.
- opensource-праект. Прапануе in-memory сховішча дадзеных, магчымасць захавання on-disk, авторазбивку на партіціі, высокую даступнасць і аднаўленне пасля сеткавых парываў.
Накшталт бы, усё выдатна, можна браць і прыкручваць - усё што трэба, ён робіць. Але паглядзім проста дзеля цікавасьці на астатніх кандыдатаў.
EhCache
- «Кеш для Java, які найбольш шырока выкарыстоўваецца» (пераклад лозунгу з афіцыйнага сайта). Таксама opensource. І тут разумеем, што Redis не пад java, а агульны, і для ўзаемадзеяння з ім патрэбна абгортка. А EhCache будзе ямчэй. Што яшчэ абяцае сістэма? Надзейнасць, праверанасць, поўнафункцыянальнасць. Ну і яшчэ яна самая распаўсюджаная. І кэшуе тэрабайты дадзеных.
Redis забыты, я гатовы абраць EhCache.
Але пачуццё патрыятызму мяне штурхае паглядзець, чым добры Tarantool.
Tarantool
- сустракае абазначэннем «Платформа інтэграцыі дадзеных у рэжыме рэальнага часу». Вельмі складана гучыць, таму чытаем старонку падрабязна і знаходзім гучную заяву: "Кешуе 100% дадзеных у аператыўнай памяці". Гэта павінна выклікаць пытанні - бо дадзеных можа быць значна больш, чым памяці. Расшыфроўка ў тым, што тут маецца на ўвазе, што для запісу дадзеных на дыск з памяці Tarantool не праганяе серыялізацыю. Замест гэтага - выкарыстоўвае нізкаўзроўневыя асаблівасці сістэмы, калі памяць проста мэпіцца на файлавую сістэму з вельмі добрымі паказчыкамі I/O. Увогуле, зрабілі неяк цудоўна і класна.
Паглядзім на ўкараненні: Mail.ru карпаратыўная магістраль, Авіта, Білайн, Мегафон, Альфа-Банк, Газпром ...
Калі заставаліся яшчэ нейкія сумневы з нагоды Tarantool, то кейс укаранення ў Mastercard мяне дабівае. Бяру Tarantool.
Але ўсё ж...
Запальвацца
… ёсць яшчэ , заяўлены як "in-memory вылічальная платформа… in-memory хуткасці на петабайтах дадзеных". Тут таксама шмат плюсаў: размеркаваны in-memory кэш, самае хуткае key-value сховішча і кэш, гарызантальнае маштабаванне, высокая даступнасць, строгая цэласнасць. Увогуле, аказваецца, самы хуткі - гэта Ignite.
Укараненні: Ашчадбанк, American Airlines, Yahoo! Japan. А потым я яшчэ даведаюся, што Ignite не проста ў Ашчадбанку ўкаранёны, а каманда АшчадТэха сваіх людзей адпраўляе ў каманду самога Ignite, дапрацоўваць прадукт. Гэта цалкам падкупляе і я гатовы ўзяць Ignite.
Зусім незразумела навошта, я гляджу на пяты пункт.
Хазелкаст
Заходжу на сайт , чытаю. І аказваецца, самае хуткае рашэнне для размеркаванага кэшавання - гэта Hazelcast. Ён на парадкі хутчэй за ўсіх іншых рашэнняў і наогул ён – лідэр у галіне in-memory data grid. На фоне гэтага ўзяць нешта іншае - сябе не паважаць. А яшчэ выкарыстоўвае залішняе захоўванне дадзеных для бесперапыннай працы кластара без страт дадзеных.
Усё, я гатовы ўзяць Hazelcast.
параўнанне
Але калі паглядзець, то ўсе пяць кандыдатаў так распісаны, што кожны з іх - самы лепшы. Як абраць? Можам паглядзець, які з іх самы папулярны, пашукаць параўнанні, і галаўны боль мінуе.
Знаходзім такі , выбіраем нашы 5 сістэм.
Тут яны адсартаваныя: наверсе Redis, на другім месцы – Hazelcast, набіраюць папулярнасць Tarantool і Ignite, EhCache як быў, так і застаецца.
Але паглядзім на : спасылкі на вэбсайты, агульны інтарэс да сістэмы, job offers - выдатна! Гэта значыць, калі ў мяне ўпадзе сістэма, я скажу: «Не, яна ж надзейная! Вось шмат прапаноў аб працы…». Такое простае параўнанне не падыдзе.
Усе гэтыя сістэмы - не проста сістэмы для кэшавання. У іх яшчэ вельмі шмат функцыяналу, у тым ліку - калі не дадзеныя перапампоўваюцца кліенту на апрацоўку, а наадварот: код, які трэба выканаць над дадзенымі, пераязджае на сервер, там выконваецца, і вынік вяртаецца. І як асобную сістэму для кэшавання іх не вось так часта і разглядаюць.
Добра, не здаемся, знойдзем прамое параўнанне сістэм. Возьмем два верхнія варыянты - Redis і Hazelcast. Нас цікавіць хуткасць, па гэтым параметры іх і параўнаем.
Hz vs Redis
Знаходзім такое :
Сіні гэта Redis, чырвоны Hazelcast. Hazelcast усюды выйграе, і гэтаму дадзена абгрунтаванне: ён шматструменны, высока аптымізаваны, кожны струмень працуе са сваёй партыцыяй, таму няма блакіровак. А Redis – аднаструменны, ад сучасных шмат'ядравых CPU ён выйгрыш не бярэ. У Hazelcast асінхроннае I/O, у Redis-Jedis – блакавальныя socket'ы. У рэшце рэшт, Hazelcast выкарыстоўвае бінарны пратакол, а Redis арыентаваны на тэкст, гэта значыць ён неэфектыўны.
На ўсякі выпадак звернемся да яшчэ адной крыніцы параўнання. Што ён нам пакажа?
Redis vs Hz
яшчэ адно :
Тут наадварот, чырвоны гэта Redis. Гэта значыць, Redis па прадукцыйнасці выйграе ў Hazelcast. У першым параўнанні выйграваў Hazelcast, у другім - Redis. вельмі дакладна растлумачылі, чаму ў папярэднім параўнанні выйграў Hazelcast.
Аказваецца, вынік першага быў фактычна падтасаваны: Redis узялі ў базавай скрынцы, а Hazelcast завастрылі пад тэставы выпадак. Тады атрымліваецца: па-першае, нікому нельга верыць, па-другое, калі мы ўсё ж такі выберам сістэму, нам яшчэ трэба яе правільна наладзіць. Гэтыя налады складаюцца з дзясяткі, амаль сотні параметраў.
Трасем бутэльку
І ўвесь працэс, які мы зараз прарабілі, я магу растлумачыць такой метафарай «Трасем бутэльку». Гэта значыць, цяпер можна не праграмаваць, зараз галоўнае - умець чытаць stackoverflow. І ў мяне ў камандзе ёсць чалавек, прафесіянал, які менавіта так і працуе ў крытычныя моманты.
Што ён робіць? Ён бачыць непрацуючую штуковіну, бачыць stack trace, бярэ нейкія з яго словы (якія менавіта – гэта яго экспертыза ў праграме), шукае ў гугле, знаходзіць stackoverflow сярод адказаў. Не чытаючы, не ўдумваючыся, сярод адказаў на пытанне - ён выбірае нешта найбольш падобнае на прапанову "зрабіць тое і тое" (выбраць такі адказ - гэта яго талент, тк не заўсёды гэта менавіта той адказ, які сабраў больш лайкаў), ужывае , глядзіць: калі нешта памянялася, то выдатна. Калі не змянілася – адкочваем. І паўтараем запуск-праверку-пошук. І такім інтуітыўным спосабам ён дамагаецца таго, што праз нейкі час код працуе. Ён не ведае чаму, ён не ведае, што ён зрабіў, ён не можа растлумачыць. Але! Гэтая зараза працуе. І "пажар патушаны". Вось зараз разбіраемся, што мы зрабілі. Калі праграма працуе - гэта на парадак лягчэй. І значна эканоміць час.
Вось гэты спосаб вельмі добрае тлумачыцца на такім прыкладзе.
Калісьці было вельмі папулярна збіраць ветразнік у бутэльцы. Пры гэтым ветразнік вялікі і далікатны, а рыльца ў бутэлькі вельмі вузкае, яго ўнутр прапіхнуць нельга. Як яго сабраць?
Ёсць такі метад, які вельмі хуткі і вельмі эфектыўны.
Карабель складаецца з кучы дробязяў: палачак, вяровачак, ветразяў, клею. Усё гэта кладзем у бутэльку.
Бярэм бутэльку двума рукамі, і пачынаем трэсці. Мы яе трасем-трасем. І звычайна атрымліваецца поўная бздура, вядома. Але часам. Часам атрымліваецца карабель! Дакладней, нешта падобнае на карабель.
Мы гэта нешта паказваем камусьці: "Сярога, бачыш!?". Здалёк - карабель. Але далей гэта пускаць нельга.
Ёсць яшчэ спосаб. Выкарыстоўваюць хлопцы больш прасунутыя, такія хакеры.
Даў такому хлопцу задачу, ён усё зрабіў і сышоў. І глядзіш - быццам зроблена. А праз некаторы час, калі трэба дапрацаваць код - там такое пачынаецца з-за яго... Добра, што ён ужо паспеў далёка адбегчы. Гэта такія хлопцы, якія на прыкладзе бутэлькі зробяць так: бачыце, там, дзе донца - шкло выгінаецца. І не зусім зразумела, празрыста яно ці не. Тады «хакеры» спілоўваюць гэта донца, устаўляюць туды карабель, донца потым прыляпляюць нанова, і як быццам так і трэба.
З пункту гледжання пастаноўкі задачы быццам усё правільна. Але вось на прыкладзе караблёў: для чаго ўвогуле рабіць гэты карабель, каму ён наогул патрэбен? Функцыянальнасць ён ніякую не нясе. Звычайна такія караблі - гэта падарункі вельмі высокапастаўленым людзям, якія ставяць яго на палічку над сабой, як некаторы сімвал, як знак. І вось калі ў такога чалавека, кіраўніка буйнога бізнэсу ці высокапастаўленага чыноўніка, як сцяг будзе стаяць такая халтура, у якой спілавана рыльца? Лепш будзе, калі ён пра гэта ніколі не даведаецца. Так, а як жа ў выніку робяць гэтыя караблі, якія можна падарыць важнаму чалавеку?
Адзінае месца, ключавое, з якім сапраўды нічога нельга зрабіць, гэта корпус. І корпус карабля якраз у рыльца праходзіць. Тады як карабель збіраецца па-за межамі бутэлькі. Але гэта не проста сабраць карабель, гэта сапраўднае ювелірнае рамяство. У складовыя часткі дадаюцца спецыяльныя рычажкі, якія дазваляюць потым іх падняць. Напрыклад, складаюцца ветразі, акуратна заносяцца ўнутр, і потым з дапамогай пінцэта вельмі ювелірна, сапраўды, іх падцягваюць і паднімаюць. У выніку атрымліваецца твор мастацтва, які можна з чыстым сумленнем і гонарам падарыць.
І калі мы хочам, каб праект быў паспяховы - у камандзе павінен быць хаця б адзін чалавек-ювелір. Той, хто клапоціцца аб якасці прадукта і ўлічвае ўсе аспекты, не ахвяруючы ніводным нават у моманты стрэсу, калі акалічнасці патрабуюць зрабіць тэрміновае ў шкоду важнаму. Усе паспяховыя праекты, якія ўстойлівыя, якія вытрымалі праверку часам, яны пабудаваны на гэтым прынцыпе. У іх ёсць нешта вельмі дакладнае і ўнікальнае, нешта, што выкарыстоўвае ўсе даступныя магчымасці. У прыкладзе з караблём у бутэльцы - абгульваецца тое, што корпус карабля праходзіць праз рыльца.
Вяртаючыся да задачы выбару нашага сервера кэшавання, як гэты спосаб можна было б прымяніць? Я прапаную такі варыянт выбару з усіх сістэм, што ёсць - не трэсці бутэльку, не выбіраць, а паглядзець, што ў прынцыпе ў іх ёсць такога, на што зважаць пры выбары сістэмы.
Дзе шукаць bottle-neck
Паспрабуем не трэсці бутэльку, не перабіраць усё што ёсць па чарзе, але паглядзім, якія задачы ўзнікнуць, калі раптам, пад сваю задачу - спраектаваць такую сістэму самастойна. Збіраць ровар, вядома ж не будзем, але скарыстаемся гэтай схемай, каб зарыентавацца, на якія моманты зважаць у апісаннях прадуктаў. Накідаем такую схему.
Калі сістэма размеркавана, значыць, у нас будзе некалькі сервераў (6). Дапушчальны, чатыры (зручна размясціць на малюнку, але, вядома, іх можа быць колькі заўгодна). Калі серверы на розных вузлах, значыць, на іх усіх круціцца некаторы код, які адказвае за тое, каб гэтыя вузлы ўтварылі кластар і ў выпадку разрыву - злучаліся, пазнавалі адзін аднаго.
Яшчэ патрэбен код-логіка (2), якая ўласна пра кэшаванне. З гэтым кодам па некаторым API узаемадзейнічаюць кліенты. Кліенцкі код (1) можа быць як у рамках гэтай жа JVM, так і звяртацца да яго па сетцы. Логіка, рэалізаваная ўнутры - гэта рашэнні, якія аб'екты ў кэшы пакідаць, якія выкідваць. Для захоўвання кэша выкарыстоўваем памяць (3), але калі запатрабуецца, частка дадзеных можам і на кружэлцы захаваць (4).
Паглядзім, у якіх частках будзе ўзнікаць нагрузка. Уласна, нагружацца будуць кожная стрэлачка і кожны вузел. Па-першае, паміж кліенцкім кодам і api, калі гэта сеткавае ўзаемадзеянне, прасяданне можа быць даволі прыкметным. Па-другое, у рамках самога api – перастараўшыся са складанай логікай, можам уперціся ў CPU. І добра было б, каб логіка не ганяла памяць лішні раз. І застаецца ўзаемадзеянне з файлавай сістэмай - у звычайным варыянце гэта серыялізаваць / аднавіць і запісаць / лічыць.
Далей узаемадзеянне з кластарам. Хутчэй за ўсё ён будзе ў гэтай жа сістэме, але можа быць і асобна. Тут таксама трэба ўлічваць перадачу даных да яго, хуткасць серыялізацыі даных і ўзаемадзеяння паміж кластарам.
Зараз, з аднаго боку - мы можам прадставіць, "якія шасцярэнькі будуць круціцца" у кэш-сістэме пры апрацоўцы запытаў ад нашага кода, і з другога боку - мы можам прыкінуць, якія і колькі запытаў наш код да гэтай сістэмы згенеруе. Гэтага дастаткова, каб зрабіць больш-менш цвярозы выбар - падабраць сістэму пад наш варыянт выкарыстання.
Хазелкаст
Паглядзім, як такое разлажэнне прымяніць да нашага спісу. Напрыклад, Hazelcast.
Для таго каб пакласці / узяць дадзеныя з Hazelcast, кліенцкі код звяртаецца (1) да api. Hz дазваляе запусціць сервер як embedded, і ў гэтым выпадку зварот да api - гэта выклік метаду ўнутры JVM, можна лічыць бясплатна.
Каб адпрацавала логіка ў (2), Hz абапіраецца на хэш ад байт-масіва серыялізаванага ключа - гэта значыць, серыялізацыя ключа адбудзецца ў любым выпадку. Гэта непазбежны overhead для Hz.
Eviction-стратэгіі рэалізаваны добра, але для асаблівых выпадкаў - можна падключаць свае. За гэтую частку можна не турбавацца.
Сховішча (4) можна падлучаць. Выдатна. Узаемадзеянне (5) для embedded можна лічыць маментальным. Абмен дадзенымі паміж вузламі ў кластары (6) - так, ён ёсць. Гэта ўклад на карысць адмоваўстойлівасці коштам хуткасці. Знізіць кошт дазваляе Hz-фіча Near-cache - дадзеныя атрыманыя з іншых нод кластара будуць закэшаваныя.
Што можна ў такіх умовах зрабіць для павышэння скорасці?
Напрыклад, каб пазбегнуць серыялізацыі ключа ў (2) - па-над Hazelcast прыкруціць яшчэ адзін кэш, для больш гарачых дадзеных. У Спортмайстар для гэтай мэты выбралі Caffeine.
Для падкруткі на ўзроўні (6), у Hz прапанаваны два тыпу захоўвання: IMap і ReplicatedMap.
Варта сказаць, як Hazelcast патрапіў у стэк тэхналогій Спортмайстар.
У 2012 годзе, калі мы працавалі над самым першым пілотам будучага сайта, менавіта Hazelcast аказаўся першай спасылкай, якую выдаў пошукавік. Знаёмства завязалася з першага разу нас падкупіла тое, што ўсяго праз дзве гадзіны, калі мы прыкруцілі Hz у сістэму ён працаваў. І працаваў добра. Да канца дня дапісалі колькі тэстаў, парадаваліся. І гэтага запасу бадзёрасці хапіла, каб пераадолець тыя неспадзеўкі, якія Hz падкідваў са часам. Цяпер у каманды Спортмайстар няма падстаў для таго, каб ад Hazelcast адмаўляцца.
Але такія аргументы, як «першая спасылка ў пошукавіку» і «хутка сабралі HelloWorld» - гэта, вядома, выключэнне і асаблівасць моманту, у якім праходзіў выбар. Сапраўдныя выпрабаванні для абранай сістэмы пачынаюцца з выхадам у прад, і менавіта на гэты этап варта звярнуць увагу пры выбары любой сістэмы, у тым ліку і кэша. Уласна, у нашым выпадку можна сказаць, што выбралі Hazelcast выпадкова, але потым аказалася, што выбралі правільна.
Для прадакшнаў шмат важней: маніторынг, апрацоўка збояў на асобных вузлах, рэплікацыя дадзеных, кошт маштабавання. Гэта значыць, варта звярнуць увагу на задачы, якія ўзнікнуць як раз у суправаджэнні сістэмы - калі нагрузка ў дзесяткі разоў перавысіць запланаваную, калі выпадкова зальем нешта не тое і не туды, калі спатрэбіцца выкаціць новую версію кода, замяніць дадзеныя і зрабіць гэта незаўважна для кліентаў.
Для ўсіх гэтых патрабаванняў, Hazelcast, безумоўна падыходзіць.
Працяг будзе
Але Hazelcast - гэта не панацэя. У 2017 годзе мы выбралі Hazelcast для кэша ў адмінцы, проста абапіраючыся на добрае ўражанне ад мінулага досведу. Гэта адыграла ключавую ролю ў вельмі злым жарце, з-за чаго мы апынуліся ў складанай сітуацыі і "гераічна" выбіраліся з яе 60 дзён. Але пра гэта, у наступнай частцы.
А пакуль... Happy New Code!
Крыніца: habr.com