Сәлеметсіз бе! Менің атым Алексей Пьянков, мен Sportmaster компаниясының әзірлеушісімін. Осыда Мен 2012 жылы Sportmaster веб-сайтындағы жұмыс қалай басталғанын, қандай бастамаларды «өткізуге» қол жеткізгенімізді және керісінше, қандай рейк жинағанымызды айттым.
Бүгін мен басқа тақырыпқа байланысты ойлармен бөліскім келеді - сайттың әкімші аймағындағы java сервері үшін кэштеу жүйесін таңдау. Бұл сюжеттің мен үшін мәні ерекше – оқиғаның өрбігеніне небәрі 2 ай болса да, осы 60 күн ішінде бірде-бір демалыссыз 12-16 сағат жұмыс істедік. Мен бұлай жұмыс істеуге болады деп ешқашан ойлаған да, елестеткен де емеспін.
Сондықтан мәтінді толық жүктемеу үшін 2 бөлікке бөлдім. Керісінше, бірінші бөлім өте жеңіл болады - дайындық, кіріспе, кэштеу деген не туралы кейбір ойлар. Егер сіз тәжірибелі әзірлеуші болсаңыз немесе кэштермен жұмыс істеген болсаңыз, техникалық жағынан бұл мақалада жаңа ештеңе болмауы мүмкін. Бірақ жасөспірім үшін мұндай шағын шолу, егер ол осындай қиылыста тапса, қай бағытты іздеу керектігін айта алады.
Sportmaster веб-сайтының жаңа нұсқасы өндіріске енгізілген кезде, деректер жұмсақ айтқанда, өте ыңғайлы емес түрде алынды. Негізі сайттың алдыңғы нұсқасына (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 жай ғана емес, өте баяу. Ол кезде біз шығарылым күніне жазылдық.
Спойлер: біз осындай үлкен мәмілені жіберіп, өткір және шиеленісті жағдайға тап болған жағдайдың қалай дамыды - мен сізге екінші бөлімде айтып беремін - және біз қалай аяқталып, қалай шықтық. Бірақ қазір мен айтайын, бұл көп стресс болды, және «ойлау - мен ойлай алмаймын, біз бөтелкені шайқаймыз». «Шөлмекті шайқау» да спойлер, бұл туралы кейінірек.
Біз не істедік:
- Біз Google және StackOverflow ұсынатын барлық жүйелердің тізімін жасаймыз. 30-дан сәл жоғары
- Біз сынақтарды өндіріске тән жүктемемен жазамыз. Ол үшін біз жүйе арқылы өндірістік ортада өтетін деректерді жазып алдық – бұл желіде емес, жүйе ішіндегі деректер үшін снайфер түрі. Дәл осы деректер сынақтарда пайдаланылды.
- Бүкіл топпен барлығы тізімнен келесі жүйені таңдап, оны конфигурациялайды және сынақтарды жүргізеді. Ол сынақтан өтпейді, жүк көтермейді - біз оны лақтырып, келесі кезекке көшеміз.
- 17-ші жүйеде бәрі үмітсіз екені белгілі болды. Бөтелкені шайқауды тоқтатыңыз, байыпты ойланатын кез келді.
Бірақ бұл алдын ала дайындалған сынақтарда «жылдамдықты жеңетін» жүйені таңдау қажет болған кездегі нұсқа. Егер мұндай сынақтар әлі жоқ болса және сіз тез таңдағыңыз келсе ше?
Осы опцияны модельдеп көрейік (орташа+ әзірлеуші вакуумда өмір сүретінін елестету қиын, және іріктеу кезінде қай өнімді бірінші болып сынап көру керектігі туралы өз қалауын әлі ресімдемеген - сондықтан одан әрі дәлелдеу теоретик/философия) кіші туралы).
Талаптарды шешіп, қораптан шешім таңдауды бастайық. Неліктен дөңгелекті қайта ойлап табу керек: біз барып, дайын кэштеу жүйесін аламыз.
Егер сіз жаңадан бастасаңыз және оны гуглдан іздесеңіз, тапсырыс беріңіз немесе алыңыз, бірақ жалпы нұсқаулар осындай болады. Ең алдымен сіз Редиске кезігесіз, ол барлық жерде естіледі. Содан кейін сіз EhCache ең көне және ең дәлелденген жүйе екенін білесіз. Келесіде біз шешімнің бірегей аспектісі бар отандық әзірлеме Tarantool туралы жазамыз. Сондай-ақ Ignite, өйткені ол қазір танымалдылыққа ие және SberTech қолдауына ие. Соңында Hazelcast да бар, өйткені кәсіпорын әлемінде ол жиі ірі компаниялар арасында пайда болады.
Тізім толық емес, ондаған жүйе бар. Және біз тек бір нәрсені бұзамыз. «Сұлулық байқауына» таңдалған 5 жүйені алып, таңдау жасайық. Жеңімпаз кім болады?
Редис
Олардың не жазғанын ресми сайттан оқимыз.
- ашық бастапқы жоба. Жадтағы деректерді сақтауды, дискіде сақтау мүмкіндігін, автоматты түрде бөлуді, жоғары қолжетімділікті және желідегі үзілістерден қалпына келтіруді ұсынады.
Бәрі жақсы сияқты, сіз оны алып, бұрауға болады - сізге қажет нәрсенің бәрі жасайды. Бірақ көңіл көтеру үшін басқа үміткерлерді қарастырайық.
EhCache
- «Java үшін ең көп қолданылатын кэш» (ресми веб-сайттан ұранның аудармасы). Сондай-ақ ашық көзі. Содан кейін біз Redis java үшін емес, жалпы екенін түсінеміз және онымен әрекеттесу үшін сізге қаптама қажет. Ал EhCache ыңғайлырақ болады. Жүйе тағы не уәде етеді? Сенімділік, дәлелденген, толық функционалдылық. Сонымен қатар, бұл ең көп таралған. Және терабайт деректерді кэштейді.
Redis ұмытылды, мен EhCache таңдауға дайынмын.
Бірақ патриоттық сезім мені Tarantool туралы не жақсы екенін көруге итермелейді.
Тарантол
- «Нақты уақыттағы деректерді біріктіру платформасы» белгісіне сәйкес келеді. Бұл өте күрделі болып көрінеді, сондықтан біз бетті егжей-тегжейлі оқып, қатты мәлімдеме табамыз: «ЖЖҚ-дағы деректердің 100% кэштейді». Бұл сұрақтар тудыруы керек - ақыр соңында, жадқа қарағанда әлдеқайда көп деректер болуы мүмкін. Түсініктеме мынада, бұл Tarantool жадтан дискіге деректерді жазу үшін сериялауды іске қоспайды. Оның орнына ол жад өте жақсы енгізу/шығару өнімділігі бар файлдық жүйемен салыстырылған кезде жүйенің төмен деңгейлі мүмкіндіктерін пайдаланады. Жалпы, олар керемет және керемет нәрсе жасады.
Іске асыруларды қарастырайық: Mail.ru корпоративтік тас жолы, Авито, Билайн, Мегафон, Альфа-Банк, Газпром...
Егер Tarantool-ға әлі де күмәнданатын болсаңыз, Mastercard-тағы іске асыру ісі мені аяқтайды. Мен Tarantool аламын.
Бірақ бәрібір…
жандыру
… тағы бар , «жадтағы есептеу платформасы... петабайт деректердегі жадтағы жылдамдықтар» ретінде есептелген. Мұнда да көптеген артықшылықтар бар: бөлінген жадтағы кэш, ең жылдам кілт-мәнді сақтау және кэш, көлденең масштабтау, жоғары қолжетімділік, қатаң тұтастық. Жалпы, ең жылдам - Ignite болып шықты.
Іске асыру: Сбербанк, American Airlines, Yahoo! Жапония. Содан кейін мен Ignite Сбербанкте жай ғана енгізілгенін білдім, бірақ SberTech командасы өнімді жетілдіру үшін Ignite командасына өз адамдарын жібереді. Бұл өте қызықты және мен Ignite қабылдауға дайынмын.
Неге екені белгісіз, мен бесінші тармаққа қарап отырмын.
Хазелкаст
Мен сайтқа кіремін , оқу. Ал таратылған кэштеу үшін ең жылдам шешім Hazelcast болып табылады. Бұл барлық басқа шешімдерге қарағанда жылдамырақ және жалпы жадтағы деректер торы саласындағы көшбасшы болып табылады. Осыған қарамастан, басқа нәрсені алу - өзіңізді құрметтеу емес. Ол сонымен қатар деректерді жоғалтпай кластердің үздіксіз жұмыс істеуі үшін артық деректерді сақтауды пайдаланады.
Міне, мен Хазелкастты қабылдауға дайынмын.
Салыстыру
Бірақ қарасаңыз, бес үміткердің де әрқайсысы ең жақсы деп сипатталған. Қалай таңдау керек? Қайсысы ең танымал екенін көреміз, салыстыруды іздейміз, бас ауруы басылады.
Біз осындай біреуін табамыз , біздің 5 жүйені таңдаңыз.
Мұнда олар сұрыпталған: Redis жоғарғы жағында, Hazelcast екінші орында, Tarantool және Ignite танымал болуда, EhCache бұрынғысынша болды және солай болып қалады.
Бірақ қарайық : веб-сайттарға сілтемелер, жүйеге жалпы қызығушылық, жұмыс ұсыныстары - тамаша! Яғни, менің жүйем сәтсіздікке ұшыраған кезде мен: «Жоқ, бұл сенімді! Көптеген жұмыс ұсыныстары бар...» Мұндай қарапайым салыстыру жұмыс істемейді.
Бұл жүйелердің барлығы тек кэштеу жүйелері емес. Сондай-ақ олардың көптеген функционалдығы бар, соның ішінде деректерді өңдеу үшін клиентке айдалмаған кезде, бірақ керісінше: деректерде орындалуы керек код серверге ауысады, сол жерде орындалады және нәтиже қайтарылады. Және олар кэштеу үшін жеке жүйе ретінде жиі қарастырылмайды.
Жарайды, берілмейік, жүйелердің тікелей салыстыруын табайық. Ең жақсы екі нұсқаны алайық - Redis және Hazelcast. Бізді жылдамдық қызықтырады және біз оларды осы параметр негізінде салыстырамыз.
Гц және Редис
Біз мұны табамыз :
Көк - Редис, қызыл - Хазелкаст. Hazelcast барлық жерде жеңеді және бұл үшін негіздеме бар: ол көп ағынды, жоғары оңтайландырылған, әрбір ағын өз бөлімімен жұмыс істейді, сондықтан блоктау жоқ. Және Redis бір ағынды болып табылады; ол заманауи көп ядролы процессорлардан пайда көрмейді. Hazelcast-тың асинхронды енгізу-шығару, Redis-Jedis-те блоктау розеткалары бар. Өйткені, Hazelcast екілік протоколды пайдаланады, ал Redis мәтінге бағытталған, яғни ол тиімсіз.
Мүмкін болса, басқа салыстыру көзіне жүгінейік. Ол бізге не көрсетеді?
Редис пен Гц
Басқа :
Мұнда, керісінше, қызыл - Редис. Яғни, Редис өнімділігі жағынан Hazelcast-тан асып түседі. Бірінші салыстыруда Хазелкаст, екіншісінде Редис жеңіске жетті. Хазелкаст неліктен алдыңғы салыстыруда жеңгенін өте дәл түсіндірді.
Біріншісінің нәтижесі шынымен бұрмаланғаны белгілі болды: Редис негізгі қорапта алынды, ал Хазелкаст сынақ корпусына бейімделген. Содан кейін белгілі болады: біріншіден, біз ешкімге сене алмаймыз, екіншіден, жүйені таңдаған кезде, біз оны әлі де дұрыс конфигурациялауымыз керек. Бұл параметрлер ондаған, жүздеген дерлік параметрлерді қамтиды.
Бөтелкені шайқау
Мен қазір біз жасаған бүкіл процесті келесі метафорамен түсіндіре аламын: «Шөлмекті шайқау». Яғни, енді сізге бағдарламалаудың қажеті жоқ, енді ең бастысы - stackoverflow оқи білу. Менің командамда сын сағаттарда дәл осылай жұмыс істейтін кәсіби маман бар.
Ол не істеп жатыр? Ол сынған нәрсені көреді, стек ізін көреді, одан кейбір сөздерді алады (бұл оның бағдарламадағы тәжірибесі), Google-дан іздейді, жауаптар арасында стековерфластын табады. Оқымай-ақ, ойланбастан, сұраққа жауаптардың ішінен ол «мынаны істе» деген сөйлемге ең ұқсас нәрсені таңдайды (мұндай жауапты таңдау - оның таланты, өйткені бұл әрқашан ең көп лайк жинаған жауап бола бермейді), қолданылады , көрінеді: егер бірдеңе өзгерсе, тамаша. Егер ол өзгермесе, оны артқа айналдырыңыз. Және іске қосу-тексеру-іздеу әрекетін қайталаңыз. Және бұл интуитивті жолмен ол кодтың біраз уақыттан кейін жұмыс істеуін қамтамасыз етеді. Неге екенін білмейді, не істегенін білмейді, түсіндіре алмайды. Бірақ! Бұл инфекция жұмыс істейді. Және «өрт сөндірілді». Енді не істегенімізді анықтайық. Бағдарлама жұмыс істегенде, бұл оңайырақ. Және бұл көп уақытты үнемдейді.
Бұл әдіс осы мысалмен өте жақсы түсіндіріледі.
Бір кездері желкенді қайықты бөтелкеге жинау өте танымал болды. Сонымен бірге желкенді қайық үлкен және нәзік, ал бөтелкенің мойны өте тар, оны ішке итеру мүмкін емес. Оны қалай құрастыруға болады?
Мұндай әдіс бар, өте жылдам және өте тиімді.
Кеме бірнеше ұсақ заттардан тұрады: таяқтар, арқандар, желкендер, желім. Мұның бәрін бөтелкеге саламыз.
Бөтелкені екі қолмен алып, шайқай бастаймыз. Біз оны шайқаймыз және шайқаймыз. Және әдетте бұл толық қоқыс болып шығады, әрине. Бірақ кейде. Кейде ол кеме болып шығады! Дәлірек айтқанда, кемеге ұқсас нәрсе.
Біз мұны біреуге көрсетеміз: «Серёга, көріп тұрсың ба!?» Шынында да, алыстан ол кемеге ұқсайды. Бірақ мұны жалғастыруға жол беруге болмайды.
Басқа жолы бар. Оларды хакерлер сияқты озық жігіттер пайдаланады.
Мен бұл жігітке тапсырма бердім, ол бәрін істеді де кетті. Ал сіз қарап отырсыз - бұл орындалған сияқты. Біраз уақыттан кейін кодты аяқтау қажет болғанда, бұл оның кесірінен басталады... Оның алысқа қашып үлгергені жақсы. Бөтелкені мысалға ала отырып, мынау жігіттер: көрдің бе, түбі қай жерде, әйнек қайырылады. Ал оның мөлдір ме, жоқ па, ол толығымен анық емес. Содан кейін «хакерлер» бұл түбін кесіп тастап, сол жерге кеме кіргізеді, содан кейін түбін қайтадан желімдейді және бұл солай болуы керек сияқты.
Мәселені қою тұрғысынан алғанда, бәрі дұрыс сияқты. Бірақ мысал ретінде кемелерді пайдалану: бұл кемені неге жасау керек, бәрібір ол кімге керек? Ол ешқандай функционалдылықты қамтамасыз етпейді. Әдетте мұндай кемелер өте жоғары дәрежелі адамдарға сыйлық болып табылады, олар оны өздерінің үстіндегі сөреге қандай да бір белгі, белгі ретінде қояды. Ал егер мұндай адам, ірі кәсіпорынның басшысы немесе жоғары лауазымды шенеунік болса, мойыны кесілген бұзақылыққа қалай ту шыдайды? Ол бұл туралы ешқашан білмесе жақсы болар еді. Сонымен, олар маңызды адамға берілуі мүмкін кемелерді қалай жасайды?
Сіз шынымен ештеңе істей алмайтын жалғыз басты орын - бұл дене. Ал кеменің корпусы мойынға тура келеді. Ал кеме бөтелкеден тыс жиналған. Бірақ бұл кеме құрастыру ғана емес, бұл нағыз зергерлік қолөнер. Құрамдас бөліктерге арнайы тұтқалар қосылады, олар кейін оларды көтеруге мүмкіндік береді. Мысалы, желкендерді бүктеп, мұқият ішке кіргізеді, содан кейін пинцет көмегімен өте дәл, дәлдікпен тартып, жоғары көтереді. Нәтижесі – таза ар мен мақтанышпен дарынды өнер туындысы.
Ал жоба сәтті болсын десек, командада кем дегенде бір зергер болуы керек. Өнімнің сапасына мән беретін және барлық аспектілерді ескеретін адам, тіпті күйзеліске ұшыраған сәттерінде де, маңыздының есебінен шұғыл әрекет етуді талап ететін кезде. Тұрақты, уақыт сынынан өткен барлық сәтті жобалар осы қағидаға негізделген. Оларда өте дәл және бірегей нәрсе бар, ол барлық қолда бар мүмкіндіктерді пайдаланады. Бөтелкедегі кеме бар мысалда кеменің корпусының мойыннан өтуі ойнатылады.
Біздің кэштеу серверін таңдау тапсырмасына оралсақ, бұл әдісті қалай қолдануға болады? Мен бар жүйелердің ішінен таңдаудың осы нұсқасын ұсынамын - бөтелкені шайқамаңыз, таңдамаңыз, бірақ оларда не бар екенін, жүйені таңдағанда нені іздеу керектігін қараңыз.
Бөтелке мойнын қайдан іздеу керек
Бөтелкені шайқамауға, ондағы барлық нәрсені бір-бірлеп өтпеуге тырысайық, бірақ егер біз кенеттен өз міндетіміз үшін осындай жүйені өзіміз құрастырсақ, қандай мәселелер туындайтынын көрейік. Әрине, біз велосипедті жинамаймыз, бірақ біз бұл диаграмманы өнім сипаттамаларында қандай нүктелерге назар аудару керектігін анықтауға көмектесетін боламыз. Осындай диаграмманы сызып көрейік.
Егер жүйе таратылса, онда бізде бірнеше серверлер болады (6). Төртеуі бар делік (суретте оларды орналастыру ыңғайлы, бірақ, әрине, олардың саны қалауыңызша болуы мүмкін). Егер серверлер әртүрлі түйіндерде болса, бұл олардың барлығы осы түйіндердің кластерді құруына және үзіліс жағдайында бір-бірін қосуға және тануға жауапты болатын кейбір кодты іске қосатынын білдіреді.
Сондай-ақ бізге код логикасы (2) қажет, ол шын мәнінде кэштеу туралы. Клиенттер бұл кодпен кейбір API арқылы әрекеттеседі. Клиент коды (1) бір JVM ішінде болуы немесе оған желі арқылы қол жеткізуі мүмкін. Ішінде жүзеге асырылатын логика - бұл кэште қандай нысандарды қалдыру және қайсысын тастау туралы шешім. Кэшті сақтау үшін жадты (3) пайдаланамыз, бірақ қажет болған жағдайда кейбір мәліметтерді дискіге (4) сақтай аламыз.
Жүктеме қай бөліктерде болатынын көрейік. Іс жүзінде әрбір көрсеткі және әрбір түйін жүктеледі. Біріншіден, клиент коды мен api арасында, егер бұл желілік байланыс болса, шөгу айтарлықтай байқалуы мүмкін. Екіншіден, api өзі аясында - егер біз оны күрделі логикамен асыра алсақ, процессормен проблемалар туындауы мүмкін. Логика жадқа уақыт жоғалтпаса жақсы болар еді. Файлдық жүйемен өзара әрекеттесу қалады - әдеттегі нұсқада бұл сериялау / қалпына келтіру және жазу / оқу.
Келесі - кластермен өзара әрекеттесу. Сірә, ол бір жүйеде болады, бірақ ол бөлек болуы мүмкін. Мұнда сонымен қатар оған деректерді беруді, деректерді сериялау жылдамдығын және кластер арасындағы өзара әрекетті ескеру қажет.
Енді, бір жағынан, біздің кодтан сұрауларды өңдеу кезінде кэш жүйесінде «қандай берілістердің айналатынын» елестете аламыз, ал екінші жағынан, біздің код осы жүйеге қандай және қанша сұраныс тудыратынын бағалай аламыз. Бұл көп немесе аз байсалды таңдау жасау үшін жеткілікті - біздің пайдалану жағдайымыз үшін жүйені таңдау.
Хазелкаст
Бұл ыдырауды біздің тізімге қалай қолдануға болатынын көрейік. Мысалы, Хазелкаст.
Hazelcast-тан деректерді қою/алу үшін клиент коды (1) api-ге қол жеткізеді. Hz серверді ендірілген ретінде іске қосуға мүмкіндік береді және бұл жағдайда api-ге қол жеткізу JVM ішіндегі әдісті шақыру болып табылады, оны тегін деп санауға болады.
(2) логика жұмыс істеуі үшін Гц серияланған кілттің байт массивінің хэшіне сүйенеді - яғни кілт кез келген жағдайда серияланады. Бұл Гц үшін сөзсіз шығындар.
Көшіру стратегиялары жақсы жүзеге асырылады, бірақ ерекше жағдайларда сіз өзіңіздің стратегияңызды қоса аласыз. Бұл бөлік туралы алаңдамаудың қажеті жоқ.
Жадты (4) қосуға болады. Тамаша. Енгізілген үшін өзара әрекеттесу (5) лезде қарастырылуы мүмкін. Кластердегі түйіндер арасында деректер алмасу (6) - иә, ол бар. Бұл жылдамдық есебінен ақауларға төзімділікке салынған инвестиция. Hz Near-cache мүмкіндігі бағаны төмендетуге мүмкіндік береді - кластердегі басқа түйіндерден алынған деректер кэштеледі.
Мұндай жағдайларда жылдамдықты арттыру үшін не істеуге болады?
Мысалы, (2) ішіндегі кілттің сериялануын болдырмау үшін - ең ыстық деректер үшін Hazelcast үстіне басқа кэшті бекітіңіз. Осы мақсат үшін Sportmaster кофеинді таңдады.
(6) деңгейінде бұрау үшін Гц сақтаудың екі түрін ұсынады: IMap және ReplicatedMap.
Хазелкасттың Sportmaster технологиялық стекке қалай кіргенін айта кеткен жөн.
2012 жылы, біз болашақ сайттың алғашқы пилотымен жұмыс істеген кезде, іздеу жүйесі қайтарған бірінші сілтеме болып Hazelcast болды. Танысу «бірінші рет» басталды - екі сағаттан кейін жүйеге Гц-ті қосқанда, оның жұмыс істегені бізді таң қалдырды. Және бұл жақсы жұмыс істеді. Күннің соңына қарай біз бірқатар сынақтарды орындап, бақытты болдық. Және бұл күш-қуат қоры уақыт өте келе Hz. Енді Sportmaster командасының Хазелкасттан бас тартуына ешқандай себеп жоқ.
Бірақ «іздеу жүйесіндегі бірінші сілтеме» және «HelloWorld тез жиналды» сияқты дәлелдер, әрине, таңдау болған сәтте ерекшелік және ерекшелік болып табылады. Таңдалған жүйе үшін нақты сынақтар өндіріске шығарудан басталады және дәл осы кезеңде кез келген жүйені, соның ішінде кэшті таңдағанда назар аудару керек. Шындығында, біздің жағдайда біз Hazelcast-ты кездейсоқ таңдадық деп айта аламыз, бірақ кейін дұрыс таңдағанымыз белгілі болды.
Өндіріс үшін әлдеқайда маңызды: бақылау, жеке түйіндердегі сәтсіздіктерді өңдеу, деректерді репликациялау, масштабтау құны. Яғни, жүйеге техникалық қызмет көрсету кезінде туындайтын міндеттерге назар аударған жөн - жүктеме жоспарланғаннан ондаған есе жоғары болғанда, біз кездейсоқ бір нәрсені дұрыс емес жерге жүктегенде, жаңа нұсқаны шығару қажет болғанда. кодты өзгертіңіз, деректерді ауыстырыңыз және оны клиенттер үшін байқамай жасаңыз.
Барлық осы талаптар үшін Hazelcast, әрине, заң жобасына сәйкес келеді.
Жалғасы бар
Бірақ Hazelcast - бұл панацея емес. 2017 жылы біз әкімші кэші үшін өткен тәжірибеден алған жақсы әсерлерге негізделген Hazelcast-ты таңдадық. Бұл өте қатыгез әзілде шешуші рөл атқарды, соның салдарынан біз қиын жағдайға тап болдық және 60 күн бойы одан «қаһармандықпен» шықтық. Бірақ бұл туралы толығырақ келесі бөлімде.
Әзірше... Жаңа код құтты болсын!
Ақпарат көзі: www.habr.com