Ինչպես մենք Sportmaster-ում ընտրեցինք քեշավորման համակարգը: Մաս 1

Բարեւ Ձեզ! Ես Ալեքսեյ Պյանկովն եմ, ես Sportmaster ընկերության ծրագրավորող եմ։ Դրանում գրառումը Ես պատմեցի, թե ինչպես է սկսվել աշխատանքը Sportmaster կայքում 2012 թվականին, ինչ նախաձեռնություններ ենք կարողացել «մղել» և հակառակը, ինչ փոցխ ենք հավաքել։

Այսօր ես ուզում եմ կիսվել մտքերով, որոնք հաջորդում են մեկ այլ թեմայի՝ կայքի ադմինիստրատորի վահանակում java backend-ի համար քեշավորման համակարգի ընտրություն: Այս սյուժեն ինձ համար առանձնահատուկ նշանակություն ունի. չնայած պատմությունը ծավալվեց ընդամենը 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-ը ոչ միայն դանդաղ է, այլ ահավոր դանդաղ: Եվ այդ ժամանակ մենք արդեն գրանցվել էինք թողարկման ամսաթվի համար։

Սփոյլեր. կոնկրետ ինչպե՞ս եղան հանգամանքները, որ մենք այդքան մեծ գործ բաց թողեցինք և հայտնվեցինք սուր և լարված իրավիճակում - կպատմեմ երկրորդ մասում, և ինչպես հայտնվեցինք և ինչպես դուրս եկանք: Բայց հիմա, ես պարզապես կասեմ, որ դա մեծ սթրես էր, և «մտածել, ինչ-որ կերպ ես չեմ կարող մտածել, մենք թափահարում ենք շիշը»: «Շիշը թափահարելը» նույնպես սփոյլեր է, դրա մասին ավելի ուշ:

Ինչ արեցինք.

1. Մենք կազմում ենք Google-ի և StackOverflow-ի առաջարկած բոլոր համակարգերի ցանկը: 30-ից մի փոքր ավելի
2. Մենք թեստեր ենք գրում արտադրության համար բնորոշ ծանրաբեռնվածությամբ։ Դա անելու համար մենք գրանցեցինք տվյալներ, որոնք անցնում են համակարգով արտադրական միջավայրում` տվյալների ոչ թե ցանցում, այլ համակարգի ներսում մի տեսակ խուզարկիչ: Հենց այս տվյալներն են օգտագործվել թեստերում։
3. Ամբողջ թիմով յուրաքանչյուրն ընտրում է հաջորդ համակարգը ցուցակից, կարգավորում է այն և կատարում թեստեր: Այն չի անցնում թեստը, այն չի կրում բեռը. մենք այն դեն ենք նետում և անցնում հաջորդին:
4. 17-րդ համակարգում պարզ դարձավ, որ ամեն ինչ անհույս է։ Դադարեք թափահարել շիշը, ժամանակն է լրջորեն մտածել:

Բայց սա այն տարբերակն է, երբ դուք պետք է ընտրեք համակարգ, որը «կանցնի արագությունը» նախապես պատրաստված թեստերում: Իսկ եթե դեռ նման թեստեր չկան, և դուք ցանկանում եք արագ ընտրել:

Եկեք մոդելավորենք այս տարբերակը (դժվար է պատկերացնել, որ միջին+ ծրագրավորողը ապրում է վակուումում, և ընտրության պահին դեռ չի ձևակերպել իր նախապատվությունը, թե որ ապրանքն առաջինը փորձի. հետևաբար, հետագա հիմնավորումն ավելի շատ տեսաբանություն/փիլիսոփայություն է։ կրտսերի մասին):

Որոշելով պահանջները, մենք կսկսենք լուծում ընտրել տուփից դուրս: Ինչու՞ նորից հորինել անիվը. մենք կգնանք և կվերցնենք պատրաստի քեշավորման համակարգ:

Եթե ​​նոր եք սկսում և google-ում եք այն, ապա պատվիրեք կամ վերցրեք, բայց ընդհանուր առմամբ ուղեցույցները կլինեն այսպիսին. Առաջին հերթին կհանդիպեք Ռեդիսին, այն լսվում է ամենուր։ Այնուհետև կիմանաք, որ EhCache-ն ամենահին և ապացուցված համակարգն է: Հաջորդիվ մենք կգրենք Tarantool-ի մասին՝ ներքին մշակում, որն ունի լուծման յուրահատուկ կողմ: Եվ նաև Ignite, քանի որ այն այժմ աճում է ժողովրդականության մեջ և վայելում է SberTech-ի աջակցությունը: Վերջում կա նաև Hazelcast-ը, քանի որ ձեռնարկատիրական աշխարհում այն ​​հաճախ է հայտնվում խոշոր ընկերությունների շրջանում։

Ցուցակը սպառիչ չէ, կան տասնյակ համակարգեր։ Եվ մենք միայն մի բան կխփենք. Վերցնենք ընտրված 5 համակարգերը «գեղեցկության մրցույթի» համար և ընտրություն կատարենք։ Ո՞վ է լինելու հաղթողը։

Redis

Կարդում ենք, թե ինչ են գրում պաշտոնական կայքում.
Redis - բաց կոդով նախագիծ: Առաջարկում է հիշողության մեջ տվյալների պահպանում, սկավառակի վրա պահելու հնարավորություն, ավտոմատ բաժանում, բարձր հասանելիություն և ցանցի ընդհատումներից վերականգնում:

Թվում է, թե ամեն ինչ լավ է, դուք կարող եք վերցնել այն և պտուտակել այն, այն ամենը, ինչ ձեզ հարկավոր է, դա անում է: Բայց պարզապես զվարճանալու համար, եկեք նայենք մյուս թեկնածուներին:

EhCache

EhCache - «Java-ի համար ամենաշատ օգտագործվող քեշը» (կարգախոսի թարգմանությունը պաշտոնական կայքից): Նաև opensource. Եվ հետո մենք հասկանում ենք, որ Redis-ը ոչ թե java-ի համար է, այլ ընդհանուր, և դրա հետ փոխազդելու համար անհրաժեշտ է փաթաթան: Իսկ EhCache-ն ավելի հարմար կլինի։ Էլ ի՞նչ է խոստանում համակարգը։ Հուսալիություն, ապացուցված, լիարժեք ֆունկցիոնալություն: Դե, դա նաև ամենատարածվածն է: Եվ պահում է տերաբայթ տվյալներ:

Redis-ը մոռացված է, ես պատրաստ եմ ընտրել EhCache-ը:

Բայց հայրենասիրության զգացումը մղում է ինձ տեսնելու, թե ինչն է լավ Տարանտուլում:

Տարանտուլ

Տարանտուլ - համապատասխանում է «Իրական ժամանակում տվյալների ինտեգրման հարթակ» անվանմանը: Դա շատ բարդ է թվում, ուստի մենք մանրամասն կարդում ենք էջը և գտնում բարձրաձայն հայտարարություն. «Քեշում է RAM-ի տվյալների 100%-ը»: Սա պետք է հարցեր առաջացնի. ի վերջո, կարող է շատ ավելի շատ տվյալներ լինել, քան հիշողությունը: Բացատրությունն այն է, որ դա նշանակում է, որ Tarantool-ը սերիականացում չի իրականացնում հիշողությունից սկավառակի վրա տվյալները գրելու համար։ Փոխարենը, այն օգտագործում է համակարգի ցածր մակարդակի առանձնահատկությունները, երբ հիշողությունը պարզապես քարտեզագրվում է ֆայլային համակարգի վրա, որն ունի շատ լավ I/O կատարողականություն: Ընդհանրապես, նրանք ինչ-որ հրաշալի ու թույն բան արեցին։

Դիտարկենք իրականացումները՝ Mail.ru կորպորատիվ մայրուղի, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Եթե ​​դեռևս կասկածներ կային Tarantool-ի վերաբերյալ, ապա Mastercard-ի իրականացման գործն ավարտում է ինձ: Ես վերցնում եմ Tarantool-ը:

Բայց ամեն դեպքում…

Բոցավառվել

… կա՞ ևս մի քանիսը Բոցավառվել, գանձվում է որպես «հիշողության մեջ հաշվողական հարթակ... հիշողության մեջ արագություններ պտաբայթ տվյալների վրա»։ Այստեղ կան նաև բազմաթիվ առավելություններ՝ բաշխված հիշողության քեշ, ամենաարագ բանալի արժեքի պահեստավորում և քեշ, հորիզոնական մասշտաբավորում, բարձր հասանելիություն, խիստ ամբողջականություն: Ընդհանուր առմամբ, պարզվում է, որ ամենաարագը Ignite-ն է։

Իրականացումներ՝ Sberbank, American Airlines, Yahoo! Ճապոնիա. Եվ հետո ես պարզում եմ, որ Ignite-ը ոչ միայն ներդրված է Sberbank-ում, այլ SberTech թիմն իր մարդկանց ուղարկում է հենց Ignite թիմ՝ արտադրանքը կատարելագործելու համար: Սա լիովին գրավիչ է, և ես պատրաստ եմ վերցնել Ignite-ը:

Ամբողջովին անհասկանալի է, թե ինչու, ես նայում եմ հինգերորդ կետին:

Շնդուկ

Ես գնում եմ կայք Շնդուկ, ընթերցանություն։ Եվ պարզվում է, որ բաշխված քեշավորման ամենաարագ լուծումը Hazelcast-ն է։ Այն մեծության կարգերով ավելի արագ է, քան մյուս բոլոր լուծումները և ընդհանուր առմամբ առաջատար է հիշողության տվյալների ցանցի ոլորտում: Այս ֆոնի վրա այլ բան վերցնելը նշանակում է չհարգել ինքդ քեզ։ Այն նաև օգտագործում է ավելորդ տվյալների պահեստավորում՝ առանց տվյալների կորստի կլաստերի շարունակական աշխատանքի համար:

Վերջ, ես պատրաստ եմ Հեյզելքաստ վերցնել։

Համեմատություն

Բայց եթե նայեք, բոլոր հինգ թեկնածուները նկարագրված են այնպես, որ նրանցից յուրաքանչյուրը լավագույնն է։ Ինչպե՞ս ընտրել: Տեսնենք, թե որն է ամենասիրվածը, համեմատություններ փնտրենք, ու գլխացավը կանցնի։

Մենք գտնում ենք այսպիսի մեկը ակնարկ, ընտրեք մեր 5 համակարգերը։

Այստեղ դրանք դասավորված են՝ Redis-ը վերևում է, Hazelcast-ը երկրորդ տեղում է, Tarantool-ը և Ignite-ը դառնում են ժողովրդականություն, EhCache-ը եղել և մնում է նույնը:

Բայց եկեք նայենք հաշվարկման մեթոդՀղումներ դեպի կայքեր, ընդհանուր հետաքրքրություն համակարգի նկատմամբ, աշխատանքի առաջարկներ՝ հիանալի: Այսինքն, երբ իմ համակարգը ձախողվի, ես կասեմ. «Ոչ, դա հուսալի է: Աշխատանքային առաջարկները շատ են...»: Նման պարզ համեմատությունը չի անի:

Այս բոլոր համակարգերը միայն քեշավորման համակարգեր չեն: Նրանք նաև շատ ֆունկցիոնալություն ունեն, այդ թվում, երբ տվյալները չեն ուղարկվում հաճախորդին մշակման համար, այլ հակառակը՝ այն կոդը, որը պետք է կատարվի տվյալների վրա, տեղափոխվում է սերվեր, այնտեղ կատարվում է, և արդյունքը վերադարձվում է: Եվ դրանք այնքան էլ հաճախ չեն դիտարկվում որպես քեշավորման առանձին համակարգ։

Լավ, չհանձնվենք, եկեք համակարգերի ուղիղ համեմատություն գտնենք։ Վերցնենք լավագույն երկու տարբերակները՝ Redis-ը և Hazelcast-ը: Մեզ հետաքրքրում է արագությունը, և մենք դրանք համեմատելու ենք այս պարամետրի հիման վրա:

Հց ընդդեմ Ռեդիսի

Մենք գտնում ենք սա համեմատություն:


Կապույտը Redis-ն է, կարմիրը` Hazelcast-ը: Hazelcast-ը հաղթում է ամենուր, և դրա հիմնավորումը կա. այն բազմաթելային է, շատ օպտիմիզացված է, յուրաքանչյուր թեմա աշխատում է իր բաժանմամբ, ուստի արգելափակումներ չկան: Իսկ Redis-ը մեկ թելերով է, այն չի շահում ժամանակակից բազմամիջուկ պրոցեսորներից: Hazelcast-ն ունի ասինխրոն I/O, Redis-Jedis-ն ունի արգելափակող վարդակներ: Ի վերջո, Hazelcast-ն օգտագործում է երկուական պրոտոկոլ, իսկ Redis-ը տեքստակենտրոն է, ինչը նշանակում է, որ այն անարդյունավետ է:

Ամեն դեպքում, անդրադառնանք համեմատության մեկ այլ աղբյուրի։ Ի՞նչ ցույց կտա նա մեզ։

Ռեդիս ընդդեմ Հց

Մեկ այլ համեմատություն:


Այստեղ, ընդհակառակը, կարմիրը Ռեդիսն է։ Այսինքն, Redis-ը գերազանցում է Hazelcast-ին կատարողականով։ Hazelcast-ը շահեց առաջին համեմատությունը, Redis-ը հաղթեց երկրորդում: Այստեղ շատ ճշգրիտ բացատրեց, թե ինչու Hazelcast-ը շահեց նախորդ համեմատությունը:

Պարզվում է, որ առաջինի արդյունքն իրականում կեղծվել է. Ռեդիսը վերցվել է բազային տուփի մեջ, իսկ Hazelcast-ը հարմարեցվել է թեստային գործի համար: Այնուհետև պարզվում է. նախ, մենք չենք կարող վստահել որևէ մեկին, և երկրորդը, երբ մենք վերջապես ընտրում ենք համակարգը, մենք դեռ պետք է այն ճիշտ կարգավորենք: Այս կարգավորումները ներառում են տասնյակ, գրեթե հարյուրավոր պարամետրեր:

Շիշը թափահարելով

Եվ ես կարող եմ բացատրել ամբողջ գործընթացը, որը մենք հիմա արել ենք հետևյալ փոխաբերությամբ. «Շիշը թափահարել»: Այսինքն՝ հիմա պետք չէ ծրագրավորել, հիմա գլխավորը stackoverflow-ը կարդալ կարողանալն է։ Իսկ ես իմ թիմում մարդ ունեմ՝ պրոֆեսիոնալ, որը կրիտիկական պահերին աշխատում է հենց այսպես։

Ինչ է նա անում? Նա տեսնում է կոտրված մի բան, տեսնում է ստեկի հետքը, դրանից մի քանի բառ է վերցնում (որոնք նրա փորձն են ծրագրում), որոնում է Google-ում, պատասխանների մեջ գտնում stackoverflow: Առանց կարդալու, առանց մտածելու, հարցի պատասխանների մեջ նա ընտրում է «արա այս և այն» նախադասությանն ամենանման բանը (նման պատասխան ընտրելը նրա տաղանդն է, քանի որ միշտ չէ, որ ամենաշատ հավանումները ստանում է պատասխանը), կիրառվում է, նայում է. եթե ինչ-որ բան փոխվել է, ապա հիանալի է: Եթե ​​այն չի փոխվել, հետ գլորեք այն: Եվ կրկնել գործարկում-ստուգում-որոնում: Եվ այս ինտուիտիվ եղանակով նա ապահովում է, որ կոդը որոշ ժամանակ անց աշխատի։ Նա չգիտի ինչու, չգիտի, թե ինչ է արել, չի կարող բացատրել։ Բայց! Այս վարակը գործում է. Եվ «կրակը մարված է». Հիմա եկեք պարզենք, թե ինչ ենք արել: Երբ ծրագիրն աշխատում է, մեծության կարգն ավելի հեշտ է: Եվ դա շատ ժամանակ է խնայում:

Այս մեթոդը շատ լավ բացատրվում է այս օրինակով։

Ժամանակին շատ տարածված էր առագաստանավը շշով հավաքելը: Միաժամանակ առագաստանավը մեծ է ու փխրուն, իսկ շշի վիզը շատ նեղ է, անհնար է այն ներս հրել։ Ինչպե՞ս հավաքել այն:

Նման մեթոդ կա՝ շատ արագ ու շատ արդյունավետ։

Նավը բաղկացած է մի փունջ մանրուքներից՝ ձողիկներ, պարաններ, առագաստներ, սոսինձ: Այս ամենը լցնում ենք շշի մեջ։
Երկու ձեռքով վերցնում ենք շիշը և սկսում թափահարել։ Մենք ցնցում և ցնցում ենք նրան: Եվ սովորաբար դա լրիվ աղբ է ստացվում, իհարկե։ Բայց երբեմն. Երբեմն պարզվում է, որ նավ է: Ավելի ճիշտ՝ նավի նման մի բան։

Սա ինչ-որ մեկին ցույց ենք տալիս. «Սերյոգա, տեսնու՞մ ես»: Եվ իսկապես, հեռվից այն նման է նավի։ Բայց սա չի կարելի թույլ տալ, որ շարունակվի։

Մեկ այլ ճանապարհ էլ կա. Դրանք օգտագործվում են ավելի առաջադեմ տղաների կողմից, ինչպիսիք են հաքերները:

Այս տղային առաջադրանք տվեցի, նա ամեն ինչ արեց ու գնաց։ Եվ դուք նայում եք, կարծես դա արված է: Եվ որոշ ժամանակ անց, երբ կոդը պետք է վերջնական տեսքի բերվի, սա սկսվում է նրա պատճառով... Լավ է, որ նա արդեն հասցրել է հեռու փախչել։ Սրանք այն տղաներն են, ովքեր շշի օրինակով կանեն սա՝ տեսնում եք, որտեղ հատակն է, ապակին թեքվում է։ Եվ ամբողջովին պարզ չէ՝ թափանցիկ է, թե ոչ։ Այնուհետև «հաքերները» կտրեցին այս հատակը, նավ մտցրեցին այնտեղ, այնուհետև նորից սոսնձեցին ներքևի հատվածը, և կարծես այդպես էլ պետք է լիներ:

Խնդիրը դնելու տեսանկյունից ամեն ինչ կարծես թե ճիշտ է։ Բայց նավերը որպես օրինակ օգտագործելով. ինչու՞ ընդհանրապես այս նավը սարքել, այնուամենայնիվ ո՞ւմ է դա պետք: Այն ոչ մի ֆունկցիոնալություն չի ապահովում: Սովորաբար նման նավերը նվերներ են շատ բարձրաստիճան մարդկանց, ովքեր այն դնում են իրենց վերևում գտնվող դարակում՝ որպես ինչ-որ խորհրդանիշ, որպես նշան։ Իսկ եթե այդպիսի մարդը, խոշոր բիզնեսի ղեկավարը կամ բարձրաստիճան պաշտոնյան, ինչպե՞ս է դրոշը կանգնելու նման հաքի համար, որի վիզը կտրել են։ Ավելի լավ կլիներ, որ նա երբեք չիմանա այդ մասին։ Այսպիսով, ինչպե՞ս են նրանք ավարտում պատրաստում այս նավերը, որոնք կարող են տրվել կարևոր մարդու:

Միակ առանցքային տեղը, որի մասին դուք իսկապես ոչինչ չեք կարող անել, մարմինն է: Եվ նավի կորպուսը տեղավորվում է հենց պարանոցի մեջ: Մինչդեռ նավը հավաքվում է շշից դուրս։ Բայց դա պարզապես նավ հավաքելը չէ, դա իսկական ոսկերչական արհեստ է: Բաղադրիչներին ավելացվում են հատուկ լծակներ, որոնք հետո թույլ են տալիս դրանք բարձրացնել: Օրինակ՝ առագաստները ծալվում են, խնամքով ներս են բերում, իսկ հետո պինցետների օգնությամբ շատ ճշգրիտ, ճշգրտությամբ քաշում ու բարձրացնում են։ Արդյունքը արվեստի գործ է, որը կարելի է շնորհել մաքուր խղճով և հպարտությամբ:

Իսկ եթե ուզում ենք, որ նախագիծը հաջող լինի, թիմում պետք է լինի գոնե մեկ ոսկերիչ։ Նա, ով հոգ է տանում ապրանքի որակի մասին և հաշվի է առնում բոլոր ասպեկտները՝ առանց որևէ բան զոհաբերելու, նույնիսկ սթրեսի պահերին, երբ հանգամանքները պահանջում են անել հրատապը կարևորի հաշվին։ Բոլոր հաջողված նախագծերը, որոնք կայուն են, որոնք անցել են ժամանակի փորձությունը, կառուցված են այս սկզբունքով: Նրանց մեջ կա մի շատ ճշգրիտ և եզակի մի բան, որն օգտվում է բոլոր առկա հնարավորություններից: Նավը շշի մեջ գտնվող օրինակում խաղարկվում է այն փաստը, որ նավի կորպուսն անցնում է պարանոցով։

Վերադառնալով մեր քեշավորման սերվերի ընտրության առաջադրանքին, ինչպե՞ս կարող է կիրառվել այս մեթոդը: Ես առաջարկում եմ ընտրելու այս տարբերակը գոյություն ունեցող բոլոր համակարգերից՝ մի թափահարեք շիշը, մի ընտրեք, այլ տեսեք, թե ինչ ունեն նրանք սկզբունքորեն, ինչ փնտրել համակարգ ընտրելիս:

Որտեղ փնտրել շշի պարանոց

Փորձենք շիշը չթափահարել, հերթով չանցնել այն ամենի միջով, ինչ կա, բայց տեսնենք, թե ինչ խնդիրներ կառաջանան, եթե հանկարծ, մեր առաջադրանքի համար, ինքներս նախագծենք նման համակարգ։ Իհարկե, մենք չենք հավաքի հեծանիվը, բայց մենք կօգտագործենք այս գծապատկերը՝ օգնելու մեզ պարզել, թե որ կետերին պետք է ուշադրություն դարձնել արտադրանքի նկարագրության մեջ: Եկեք ուրվագծենք նման դիագրամ.

Եթե ​​համակարգը բաշխված է, ապա մենք կունենանք մի քանի սերվեր (6): Ասենք չորսն են (հարմար է դրանք տեղադրել նկարում, բայց, իհարկե, կարող են լինել այնքան, որքան ցանկանում եք): Եթե ​​սերվերները գտնվում են տարբեր հանգույցների վրա, դա նշանակում է, որ նրանք բոլորը գործարկում են ինչ-որ կոդ, որը պատասխանատու է ապահովելու, որ այս հանգույցները կազմեն կլաստեր և, ընդմիջման դեպքում, միանան և ճանաչեն միմյանց:

Մեզ նաև անհրաժեշտ է կոդի տրամաբանություն (2), որն իրականում վերաբերում է քեշավորմանը: Հաճախորդները փոխազդում են այս կոդի հետ որոշ API-ի միջոցով: Հաճախորդի կոդը (1) կարող է լինել կամ նույն JVM-ում կամ մուտք գործել ցանցի միջոցով: Ներսում իրականացվող տրամաբանությունը որոշում է, թե որ առարկաները թողնել քեշում և որոնք դուրս նետել։ Մենք օգտագործում ենք հիշողություն (3) քեշը պահելու համար, բայց անհրաժեշտության դեպքում կարող ենք տվյալների մի մասը պահպանել սկավառակի վրա (4):

Տեսնենք, թե որ մասերում է բեռը տեղի ունենալու։ Փաստորեն, յուրաքանչյուր սլաք և յուրաքանչյուր հանգույց կբեռնվի: Նախ, հաճախորդի կոդի և api-ի միջև, եթե սա ցանցային հաղորդակցություն է, ապա անկումը կարող է բավականին նկատելի լինել: Երկրորդը, հենց api-ի շրջանակներում, եթե բարդ տրամաբանությամբ գերագնահատենք, կարող ենք պրոցեսորի հետ խնդիրներ ունենալ: Եվ լավ կլիներ, որ տրամաբանությունը ժամանակ չկորցներ հիշողության վրա։ Եվ մնում է փոխազդեցություն ֆայլային համակարգի հետ. սովորական տարբերակում սա սերիականացում / վերականգնում և գրել / կարդալ է:

Հաջորդը կլաստերի հետ փոխազդեցությունն է: Ամենայն հավանականությամբ, այն կլինի նույն համակարգում, բայց կարող է լինել առանձին։ Այստեղ դուք նույնպես պետք է հաշվի առնեք տվյալների փոխանցումը դրան, տվյալների սերիականացման արագությունը և կլաստերի միջև փոխազդեցությունը:

Այժմ, մի կողմից, մենք կարող ենք պատկերացնել, թե «ինչ շարժակներ են պտտվելու» քեշ համակարգում մեր կոդից հարցումները մշակելիս, իսկ մյուս կողմից՝ կարող ենք գնահատել, թե մեր կոդը ինչ և քանի հարցում կառաջացնի այս համակարգին: Սա բավական է քիչ թե շատ սթափ ընտրություն կատարելու համար՝ ընտրելու համակարգ մեր օգտագործման դեպքի համար։

Շնդուկ

Տեսնենք, թե ինչպես կիրառել այս տարրալուծումը մեր ցուցակում: Օրինակ, Hazelcast.

Hazelcast-ից տվյալներ տեղադրելու/վերցնելու համար հաճախորդի կոդը մուտք է գործում (1) api: Hz-ը թույլ է տալիս գործարկել սերվերը որպես ներկառուցված, և այս դեպքում api-ին մուտք գործելը մեթոդի կանչ է JVM-ի ներսում, որը կարելի է համարել անվճար:

Որպեսզի (2)-ի տրամաբանությունը աշխատի, Հց-ը հենվում է սերիականացված բանալու բայթային զանգվածի հեշի վրա, այսինքն՝ բանալին ամեն դեպքում սերիականացվելու է: Սա անխուսափելի է Հց.
Վտարման ռազմավարությունները լավ են իրականացվում, բայց հատուկ դեպքերի համար կարող եք ավելացնել ձերը: Դուք չունեք անհանգստանալու այս մասի համար:

Պահեստը (4) կարող է միացված լինել: Հիանալի: Փոխազդեցությունը (5) ներկառուցվածի համար կարելի է համարել ակնթարթային: Տվյալների փոխանակում կլաստերի հանգույցների միջև (6) - այո, այն գոյություն ունի: Սա ներդրում է սխալների հանդուրժողականության մեջ՝ արագության հաշվին: Հց ֆունկցիան Near-cache-ը թույլ է տալիս նվազեցնել գինը. կլաստերի այլ հանգույցներից ստացված տվյալները կպահվեն:

Ի՞նչ կարելի է անել նման պայմաններում արագությունը բարձրացնելու համար։

Օրինակ, (2)-ում ստեղնի սերիականացումից խուսափելու համար, կցեք ևս մեկ քեշ Hazelcast-ի վերևում՝ ամենաթեժ տվյալների համար: Sportmaster-ն այս նպատակով ընտրել է Կոֆեինը։

(6) մակարդակում ոլորելու համար Հց-ն առաջարկում է պահեստավորման երկու տեսակ՝ IMap և ReplicatedMap:


Հարկ է նշել, թե ինչպես է Hazelcast-ը հայտնվել Sportmaster տեխնոլոգիական փաթեթում:

2012թ.-ին, երբ մենք աշխատում էինք ապագա կայքի հենց առաջին օդաչուի վրա, պարզվեց, որ հենց Hazelcast-ը առաջին հղումն էր, որ վերադարձրեց որոնիչը: Ծանոթությունը սկսվեց «առաջին անգամ». մեզ գրավեց այն փաստը, որ ընդամենը երկու ժամ անց, երբ մենք պտտեցինք Հց համակարգը, այն աշխատեց: Եվ դա լավ աշխատեց: Օրվա վերջում մենք ավարտեցինք մի շարք թեստեր և ուրախ էինք: Եվ ուժի այս պաշարը բավական էր հաղթահարելու այն անակնկալները, որոնք ժամանակի ընթացքում նետեց Հցը։ Այժմ Sportmaster թիմը Hazelcast-ից հրաժարվելու պատճառ չունի:

Բայց այնպիսի փաստարկներ, ինչպիսիք են «որոնողական համակարգի առաջին հղումը» և «HelloWorld-ը արագ հավաքվել է», իհարկե, բացառություն են և այն պահի առանձնահատկությունը, երբ տեղի է ունեցել ընտրությունը: Ընտրված համակարգի իրական փորձարկումները սկսվում են արտադրության մեջ թողարկվելուց, և հենց այս փուլում է, որ պետք է ուշադրություն դարձնել ցանկացած համակարգ ընտրելիս, ներառյալ քեշը: Փաստորեն, մեր դեպքում կարելի է ասել, որ պատահաբար ենք ընտրել Hazelcast-ը, բայց հետո պարզվել է, որ ճիշտ ենք ընտրել։

Արտադրության համար շատ ավելի կարևոր է՝ մոնիտորինգ, առանձին հանգույցների խափանումների կառավարում, տվյալների կրկնօրինակում, մասշտաբավորման արժեքը: Այսինքն՝ արժե ուշադրություն դարձնել այն խնդիրներին, որոնք կառաջանան համակարգի սպասարկման ժամանակ՝ երբ ծանրաբեռնվածությունը նախատեսվածից տասնյակ անգամ ավելի է, երբ մենք պատահաբար սխալ տեղում ինչ-որ բան ենք վերբեռնում, երբ պետք է նոր տարբերակ թողարկենք։ կոդը, փոխարինեք տվյալները և կատարեք դա աննկատ հաճախորդների համար:

Այս բոլոր պահանջների համար Hazelcast-ը, անշուշտ, համապատասխանում է օրինագծին:

Շարունակելի

Բայց Hazelcast-ը համադարման չէ: 2017 թվականին մենք ընտրեցինք Hazelcast-ը ադմինիստրատորի քեշի համար՝ պարզապես անցյալ փորձից ստացված լավ տպավորությունների հիման վրա: Սա առանցքային դեր խաղաց մի շատ դաժան կատակի մեջ, որի պատճառով հայտնվեցինք ծանր վիճակում և 60 օր «հերոսաբար» դուրս եկանք։ Բայց դրա մասին ավելի շատ՝ հաջորդ մասում:

Միևնույն ժամանակ... Շնորհավոր Նոր Կոդ:

Source: www.habr.com