Գալով ավելի քան մեկ տասնամյակ զարգացող արտադրանքին, ամենևին էլ զարմանալի չէ դրա մեջ հնացած տեխնոլոգիաներ գտնելը։ Բայց ինչ անել, եթե վեց ամսվա ընթացքում դուք ստիպված լինեք պահել բեռը 10 անգամ ավելի, և ընկնելու արժեքը կավելանա հարյուրավոր անգամներ: Այս դեպքում ձեզ հարկավոր է զովացուցիչ Highload Engineer: Բայց սպասուհու բացակայության դեպքում ինձ վստահեցին խնդրի լուծումը։ Հոդվածի առաջին մասում կպատմեմ, թե ինչպես ենք Redis-ից տեղափոխվել Redis-cluster, իսկ երկրորդ մասում խորհուրդներ կտամ, թե ինչպես սկսել օգտագործել կլաստերը և ինչին ուշադրություն դարձնել այն օգտագործելիս։

Տեխնոլոգիայի ընտրություն

Արդյո՞ք դա այդքան վատ է: առանձին Redis (ինքնուրույն redis) 1 վարպետի և N ստրուկների կազմաձևում: Ինչու եմ դա անվանում հնացած տեխնոլոգիա:

Ոչ, Ռեդիսն այնքան էլ վատը չէ... Այնուամենայնիվ, կան որոշ թերություններ, որոնք չի կարելի անտեսել։

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

• Երկրորդ, միայն մեկ վարպետ ունենալը հանգեցրեց բեկորների խնդրին։ Մենք պետք է ստեղծեինք մի քանի անկախ կլաստերներ «1 վարպետ և N ստրուկներ», այնուհետև ձեռքով բաշխեցինք տվյալների բազաները այս մեքենաների միջև և հուսանք, որ վաղը տվյալների բազաներից մեկն այնքան չի ուռչի, որ այն պետք է տեղափոխվի առանձին օրինակ:

Որոնք են տարբերակները:

• Ամենաթանկ և ամենահարուստ լուծումը Redis-Enterprise-ն է։ Սա տուփային լուծում է ամբողջական տեխնիկական աջակցությամբ: Չնայած այն հանգամանքին, որ այն իդեալական տեսք ունի տեխնիկական տեսակետից, սակայն գաղափարական նկատառումներից ելնելով այն մեզ չէր սազում։
• Redis-կլաստեր. Տուփից դուրս կա աջակցություն master failover-ի և sharding-ի համար: Ինտերֆեյսը գրեթե չի տարբերվում սովորական տարբերակից: Խոստումնալից է թվում, որոգայթների մասին կխոսենք ավելի ուշ:
• Tarantool, Memcache, Aerospike և այլն: Այս բոլոր գործիքները գրեթե նույն բանն են անում: Բայց յուրաքանչյուրն ունի իր թերությունները: Մենք որոշեցինք մեր բոլոր ձվերը չդնել մեկ զամբյուղի մեջ։ Մենք օգտագործում ենք Memcache-ն ու Tarantool-ը այլ առաջադրանքների համար, և, նայելով առաջ, կասեմ, որ մեր պրակտիկայում դրանց հետ կապված խնդիրներն ավելի շատ են եղել։

Օգտագործման առանձնահատկությունները

Եկեք նայենք, թե ինչ խնդիրներ ենք մենք պատմականորեն լուծել Redis-ի հետ և ինչ գործառույթ ենք օգտագործել.

• Քեշ մինչև 2GIS-ի նման հեռակառավարվող ծառայությունների հարցումները Գոլանգ
  

  GET SET MGET MSET «SELECT DB»

• Քեշ մինչև MYSQL | PHP
  

  SET SET MGET MSET SCAN «KEY BY PATTERN» «SELECT DB»

• Սեսիաների և վարորդների կոորդինատների հետ աշխատելու ծառայության հիմնական պահեստը | Գոլանգ
  

  SET SET MGET MSET «SELECT DB» «ADD GEO KEY» «GET GEO KEY» ՍԿԱՆ

Ինչպես տեսնում եք, ոչ մի բարձրագույն մաթեմատիկա: Այդ դեպքում ո՞րն է դժվարությունը: Եկեք նայենք յուրաքանչյուր մեթոդին առանձին:

մեթոդ
Նկարագրություն
Redis-cluster-ի առանձնահատկությունները
որոշում

SET SET
Գրել/կարդալ բանալի

MGET MSET
Գրել/կարդալ բազմաթիվ ստեղներ
Ստեղները կլինեն տարբեր հանգույցների վրա: Պատրաստի գրադարանները կարող են բազմաբնույթ գործողություններ կատարել միայն մեկ հանգույցում
Փոխարինեք MGET-ը N GET գործողությունների խողովակաշարով

ԸՆՏՐԵԼ DB
Ընտրեք այն բազան, որի հետ մենք կաշխատենք
Չի աջակցում բազմաթիվ տվյալների բազաներ
Տեղադրեք ամեն ինչ մեկ տվյալների բազայում: Ավելացրեք նախածանցներ ստեղներին

SCAN
Անցեք տվյալների բազայի բոլոր ստեղները
Քանի որ մենք ունենք մեկ տվյալների բազա, կլաստերի բոլոր ստեղներով անցնելը չափազանց թանկ է
Պահպանեք ինվարիանտ մեկ ստեղնի մեջ և կատարեք HSCAN այս ստեղնի վրա: Կամ ամբողջությամբ հրաժարվել

GEO
Գործողություններ geokey-ով
Geokey-ը բեկված չէ

ԲԱՆԱԼԻ ԸՍՏ ԿԱԶՄՈՎ
Բանալի որոնում ըստ օրինաչափության
Քանի որ մենք ունենք մեկ տվյալների բազա, մենք կփնտրենք կլաստերի բոլոր ստեղները: Շատ թանկ
Հրաժարվեք կամ պահպանեք ինվարիանտը, ինչպես SCAN-ի դեպքում

Redis vs Redis-կլաստեր

Ի՞նչ ենք մենք կորցնում և ինչ ենք շահում կլաստերին անցնելիս:

• Թերությունները. մենք կորցնում ենք մի քանի տվյալների բազաների ֆունկցիոնալությունը:
  • Եթե ​​մենք ուզում ենք տրամաբանորեն անկապ տվյալներ պահել մեկ կլաստերի մեջ, ապա ստիպված կլինենք հենակներ պատրաստել նախածանցների տեսքով։
  • Մենք կորցնում ենք բոլոր «բազային» գործողությունները, ինչպիսիք են SCAN, DBSIZE, CLEAR DB և այլն:
  • Բազմաֆունկցիոնալ գործողությունները շատ ավելի դժվար են դարձել, քանի որ այն կարող է պահանջել մուտք դեպի մի քանի հանգույց:
• Պլուսեր:
  • Սխալների հանդուրժողականություն վարպետի ձախողման տեսքով:
  • Շարդինգ Ռեդիսի կողմից:
  • Տվյալների փոխանցում հանգույցների միջև ատոմային եղանակով և առանց պարապուրդի:
  • Ավելացրեք և վերաբաշխեք հզորությունը և բեռները՝ առանց պարապուրդի:

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

Պատրաստվում է շարժվել

Սկսենք տեղափոխվելու պահանջներից.

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

Կլաստերների սպասարկում

Տեղափոխվելուց անմիջապես առաջ մենք պետք է մտածենք, թե արդյոք կարող ենք աջակցել կլաստերին.

• Գծապատկերներ. Մենք օգտագործում ենք Prometheus-ը և Grafana-ն՝ գրաֆիկական պրոցեսորի բեռնվածությունը, հիշողության օգտագործումը, հաճախորդների քանակը, GET, SET, AUTH գործառնությունների քանակը և այլն:
• Փորձագիտություն. Պատկերացրեք, որ վաղը դուք կունենաք հսկայական կլաստեր ձեր պատասխանատվության տակ: Եթե ​​այն կոտրվում է, ապա ձեզնից բացի ոչ ոք չի կարող շտկել այն: Եթե ​​նա սկսի դանդաղեցնել, բոլորը կվազեն դեպի քեզ։ Եթե ​​Ձեզ անհրաժեշտ է ավելացնել ռեսուրսներ կամ վերաբաշխել բեռը, վերադարձեք ձեզ մոտ: Որպեսզի 25 տարեկանում մոխրագույն չդառնան, նպատակահարմար է նախատեսել այս դեպքերը և նախապես ստուգել, ​​թե ինչպես կվարվի տեխնոլոգիան որոշակի գործողությունների ներքո: Այս մասին ավելի մանրամասն խոսենք «Փորձաքննություն» բաժնում:
• Մոնիտորինգ և ահազանգեր: Երբ կլաստերը փչանում է, դուք ցանկանում եք առաջինն իմանալ դրա մասին: Այստեղ մենք սահմանափակվեցինք ծանուցմամբ, որ բոլոր հանգույցները վերադարձնում են նույն տեղեկատվությունը կլաստերի վիճակի մասին (այո, դա տեղի է ունենում այլ կերպ): Իսկ այլ խնդիրներ կարող են ավելի արագ նկատել Redis-ի հաճախորդների ծառայությունների ահազանգերի միջոցով:

Շարժվող

Ինչպես ենք մենք շարժվելու.

• Նախևառաջ պետք է գրադարան պատրաստել կլաստերի հետ աշխատելու համար: Մենք վերցրեցինք go-redis-ը որպես Go տարբերակի հիմք և մի փոքր փոխեցինք այն մեզ հարմարվելու համար: Մենք իրականացրել ենք Multi-methods խողովակաշարերի միջոցով, ինչպես նաև մի փոքր շտկել ենք կրկնվող հարցումների կանոնները: PHP տարբերակն ավելի շատ խնդիրներ ուներ, բայց ի վերջո մենք որոշեցինք php-redis-ի վրա: Նրանք վերջերս ներկայացրեցին կլաստերային աջակցություն, և դա լավ է մեր կարծիքով:
• Հաջորդը դուք պետք է տեղակայեք կլաստերը ինքնին: Սա կատարվում է բառացիորեն երկու հրամաններով, որոնք հիմնված են կազմաձևման ֆայլի վրա: Ստորև մենք ավելի մանրամասն կքննարկենք կարգավորումը:
• Աստիճանաբար շարժվելու համար մենք օգտագործում ենք չոր ռեժիմ: Քանի որ մենք ունենք գրադարանի երկու տարբերակ՝ միևնույն ինտերֆեյսով (մեկը սովորական տարբերակի, մյուսը՝ կլաստերի համար), ոչինչ չարժե ստեղծել փաթաթան, որը կաշխատի առանձին տարբերակով և զուգահեռաբար կրկնօրինակում է բոլոր հարցումները կլաստերին, համեմատեք պատասխանները և գրեք անհամապատասխանություններ գրանցամատյաններում (մեր դեպքում՝ NewRelic-ում): Այսպիսով, նույնիսկ եթե կլաստերի տարբերակը խախտվի թողարկման ընթացքում, մեր արտադրությունը չի ազդի:
• Կլաստերը չոր ռեժիմով գլորելով՝ մենք կարող ենք հանգիստ նայել պատասխանների անհամապատասխանությունների գրաֆիկին: Եթե ​​սխալի մակարդակը դանդաղ, բայց հաստատապես շարժվում է դեպի ինչ-որ փոքր հաստատուն, ապա ամեն ինչ լավ է: Ինչու՞ դեռ կան անհամապատասխանություններ. Քանի որ առանձին տարբերակով ձայնագրումը տեղի է ունենում մի փոքր ավելի վաղ, քան կլաստերում, և միկրոլագի պատճառով տվյալները կարող են տարբերվել: Մնում է միայն նայել անհամապատասխանությունների մատյանները, և եթե դրանք բոլորը բացատրվում են գրառման ոչ ատոմականությամբ, ապա մենք կարող ենք առաջ շարժվել:
• Այժմ դուք կարող եք փոխել չոր ռեժիմը հակառակ ուղղությամբ: Մենք կգրենք և կկարդանք կլաստերից և այն կկրկնօրինակենք առանձին տարբերակի մեջ: Ինչի համար? Հաջորդ շաբաթվա ընթացքում ես կցանկանայի դիտարկել կլաստերի աշխատանքը: Եթե ​​հանկարծ պարզվի, որ ծանրաբեռնվածության գագաթնակետին խնդիրներ կան, կամ մենք ինչ-որ բան հաշվի չենք առել, ապա չոր ռեժիմի շնորհիվ մենք միշտ շտապ հետադարձ ենք կատարում հին ծածկագրին և ընթացիկ տվյալներին:
• Մնում է անջատել չոր ռեժիմը և ապամոնտաժել առանձին տարբերակը:

Փորձագիտություն

Նախ, հակիրճ կլաստերի դիզայնի մասին:

Նախևառաջ, Redis-ը առանցքային արժեք ունեցող խանութ է: Որպես բանալիներ օգտագործվում են կամայական տողեր։ Թվերը, տողերը և ամբողջ կառուցվածքները կարող են օգտագործվել որպես արժեքներ: Վերջիններս շատ են, բայց ընդհանուր կառուցվածքը հասկանալու համար դա մեզ համար կարևոր չէ։
Բանալից հետո աբստրակցիայի հաջորդ մակարդակը սլոտներն են (SLOTS): Յուրաքանչյուր բանալի պատկանում է 16 բնիկներից մեկին: Յուրաքանչյուր բնիկի ներսում կարող է լինել ցանկացած թվով բանալի: Այսպիսով, բոլոր ստեղները բաժանված են 383 տարանջատված հավաքածուների:

Հաջորդը, կլաստերում պետք է լինի N հիմնական հանգույց: Յուրաքանչյուր հանգույց կարելի է դիտարկել որպես առանձին Redis օրինակ, որը գիտի ամեն ինչ կլաստերի մյուս հանգույցների մասին: Յուրաքանչյուր հիմնական հանգույց պարունակում է մի շարք slots: Յուրաքանչյուր բնիկ պատկանում է միայն մեկ հիմնական հանգույցի: Բոլոր սլոտները պետք է բաշխվեն հանգույցների միջև: Եթե ​​որոշ սլոտներ չեն հատկացվել, ապա դրանցում պահվող բանալիներն անհասանելի կլինեն: Իմաստ ունի յուրաքանչյուր հիմնական հանգույց գործարկել առանձին տրամաբանական կամ ֆիզիկական մեքենայի վրա: Հարկ է նաև հիշել, որ յուրաքանչյուր հանգույց աշխատում է միայն մեկ միջուկի վրա, և եթե ցանկանում եք գործարկել մի քանի Redis օրինակներ նույն տրամաբանական մեքենայի վրա, համոզվեք, որ դրանք աշխատում են տարբեր միջուկների վրա (մենք չենք փորձել դա, բայց տեսականորեն այն պետք է աշխատի) . Ըստ էության, հիմնական հանգույցները ապահովում են կանոնավոր բեկում, և ավելի շատ հիմնական հանգույցներ թույլ են տալիս չափել գրելու և կարդալու հարցումները:

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

Հիմա անդրադառնանք վիրահատություններին, որոնք ավելի լավ կլիներ, որ կարողանայինք անել։

Մենք համակարգ մուտք կունենանք Redis-CLI-ի միջոցով: Քանի որ Redis-ը չունի մեկ մուտքի կետ, դուք կարող եք կատարել հետևյալ գործողությունները ցանկացած հանգույցի վրա. Յուրաքանչյուր կետում ես առանձին ուշադրություն եմ հրավիրում բեռի տակ գործողությունը կատարելու հնարավորության վրա:

• Առաջին և ամենակարևոր բանը, որ մեզ անհրաժեշտ է, կլաստերի հանգույցների գործառնությունն է: Այն վերադարձնում է կլաստերի վիճակը, ցույց է տալիս հանգույցների ցանկը, դրանց դերերը, բնիկների բաշխումը և այլն։ Լրացուցիչ տեղեկություններ կարելի է ստանալ՝ օգտագործելով կլաստերի տվյալները և կլաստերի սլոտերը:
• Լավ կլինի, որ կարողանանք հանգույցներ ավելացնել և հեռացնել: Այդ նպատակով գոյություն ունեն կլաստերի հանդիպում և կլաստերի մոռացության գործողություններ: Խնդրում ենք նկատի ունենալ, որ կլաստերի մոռացումը պետք է կիրառվի ՅՈՒՐԱՔԱՆՉՅՈՒՐ հանգույցի վրա՝ և՛ վարպետների, և՛ կրկնօրինակների: Իսկ cluster meet-ը պետք է կանչվի միայն մեկ հանգույցում: Այս տարբերությունը կարող է անհանգստացնող լինել, ուստի ավելի լավ է իմանալ դրա մասին նախքան ձեր կլաստերի հետ ուղիղ եթեր դուրս գալը: Հանգույց ավելացնելը մարտում կատարվում է անվտանգ և ոչ մի կերպ չի ազդում կլաստերի աշխատանքի վրա (ինչը տրամաբանական է): Եթե ​​դուք պատրաստվում եք հանգույցից հեռացնել կլաստերից, ապա պետք է համոզվեք, որ դրա վրա ոչ մի տեղ չի մնացել (հակառակ դեպքում, դուք ռիսկի կհանեք այս հանգույցի բոլոր ստեղների հասանելիությունը): Նաև մի ջնջեք ստրուկներ ունեցող տիրոջը, այլապես անհարկի քվեարկություն կկատարվի նոր տիրոջ համար։ Եթե ​​հանգույցներն այլևս չունեն սլոտներ, ապա սա փոքր խնդիր է, բայց ինչու են մեզ անհրաժեշտ լրացուցիչ ընտրություններ, եթե մենք կարող ենք նախ ջնջել ստրուկները:
• Եթե ​​Ձեզ անհրաժեշտ է ստիպողաբար փոխել հիմնական և ստրուկ դիրքերը, ապա կլաստերի ձախողման հրամանը կգործի: Այն մարտի մեջ կանչելիս պետք է հասկանալ, որ գործողության ընթացքում վարպետը հասանելի չի լինի։ Սովորաբար անջատիչը տեղի է ունենում մեկ վայրկյանից պակաս ժամանակում, բայց ատոմային չէ: Կարող եք ակնկալել, որ վարպետին ուղղված որոշ հարցումներ այս ընթացքում ձախողվելու են:
• Նախքան հանգույցը կլաստերից հեռացնելը, դրա վրա բացվածքներ չպետք է մնան: Ավելի լավ է դրանք վերաբաշխել՝ օգտագործելով կլաստերի reshard հրամանը: Սլոտները կտեղափոխվեն մի վարպետից մյուսը: Ամբողջ գործողությունը կարող է տևել մի քանի րոպե, դա կախված է փոխանցվող տվյալների ծավալից, սակայն փոխանցման գործընթացը անվտանգ է և որևէ կերպ չի ազդում կլաստերի աշխատանքի վրա: Այսպիսով, բոլոր տվյալները կարող են փոխանցվել մի հանգույցից մյուսը անմիջապես բեռի տակ և առանց անհանգստանալու դրա առկայության մասին: Այնուամենայնիվ, կան նաև նրբություններ. Նախ, տվյալների փոխանցումը կապված է ստացողի և ուղարկողի հանգույցների որոշակի բեռի հետ: Եթե ​​ստացողի հանգույցն արդեն մեծապես բեռնված է պրոցեսորի վրա, ապա դուք չպետք է բեռնեք այն նոր տվյալներ ստանալու միջոցով: Երկրորդ, հենց որ ուղարկող վարպետի վրա ոչ մի բնիկ չմնա, նրա բոլոր ստրուկներն անմիջապես կգնան այն վարպետի մոտ, որին փոխանցվել են այդ բնիկները: Եվ խնդիրն այն է, որ այս բոլոր ստրուկները կցանկանան համաժամեցնել տվյալները միանգամից: Եվ դուք հաջողակ կլինեք, եթե դա լինի մասնակի, այլ ոչ թե ամբողջական համաժամացման: Հաշվի առեք սա և համատեղեք սլոտների փոխանցման և ստրուկների անջատման/փոխանցման գործողությունները: Կամ հուսալ, որ դուք ունեք անվտանգության բավարար սահման:
• Ի՞նչ պետք է անեք, եթե փոխանցման ընթացքում հայտնաբերեք, որ ինչ-որ տեղ կորցրել եք ձեր խաղային կետերը: Հուսով եմ, որ այս խնդիրը չի ազդի ձեզ վրա, բայց եթե դա ազդում է, ապա կա կլաստերի շտկման գործողություն: Առնվազն, նա պատահական կարգով կցրի անցքերը հանգույցների վրա: Ես խորհուրդ եմ տալիս ստուգել դրա աշխատանքը՝ նախ կլաստերից հեռացնելով բաշխված սլոտներով հանգույցը: Քանի որ չբաշխված սլոտների տվյալներն արդեն անհասանելի են, շատ ուշ է անհանգստանալու այս սլոտների առկայության հետ կապված խնդիրների մասին: Իր հերթին, գործողությունը չի ազդի բաշխված սլոտների վրա:
• Մեկ այլ օգտակար գործողություն մոնիտորն է: Այն թույլ է տալիս իրական ժամանակում տեսնել դեպի հանգույց գնացող հարցումների ողջ ցանկը: Ավելին, դուք կարող եք հասկանալ այն և պարզել, թե արդյոք կա անհրաժեշտ տրաֆիկ:

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

Տեսիլ

Հաճախ կոնֆիգուրացիան առաջին բանն է, որ դուք պետք է սկսեք աշխատել գործիքի հետ: Եվ երբ ամեն ինչ աշխատում է, դուք նույնիսկ չեք ցանկանում դիպչել կազմաձևին: Որոշակի ջանք է պահանջվում՝ ստիպելու ձեզ վերադառնալ կարգավորումներին և ուշադիր անցնել դրանք: Իմ հիշողության մեջ մենք առնվազն երկու լուրջ ձախողում ենք ունեցել կոնֆիգուրացիայի նկատմամբ անուշադրության պատճառով: Հատուկ ուշադրություն դարձրեք հետևյալ կետերին.

• ելք 0
  Ժամանակ, որից հետո ոչ ակտիվ կապերը փակվում են (վայրկյաններով): 0 - մի փակիր
  Մեր ամեն գրադարան չէ, որ կարողացավ ճիշտ փակել կապերը։ Անջատելով այս պարամետրը, մենք ռիսկի ենք դիմում սպառել հաճախորդների թվի սահմանաչափը: Մյուս կողմից, եթե նման խնդիր կա, ապա կորցրած կապերի ավտոմատ դադարեցումը կքողարկի այն, և մենք կարող ենք չնկատել: Բացի այդ, դուք չպետք է միացնեք այս կարգավորումը մշտական ​​կապեր օգտագործելիս:
• Պահպանեք xy և միայն այո
  RDB պատկերի պահպանում:
  Ստորև մենք մանրամասն կքննարկենք RDB/AOF խնդիրները:
• stop-writes-on-bgsave-error no & slave-serve-stale-data այո
  Եթե ​​միացված է, եթե RDB-ի լուսանկարը կոտրվի, վարպետը կդադարեցնի փոփոխության հարցումների ընդունումը: Եթե ​​կապը վարպետի հետ կորչում է, ստրուկը կարող է շարունակել պատասխանել հարցումներին (այո): Կամ կդադարի պատասխանել (ոչ)
  Մենք գոհ չենք այն իրավիճակից, երբ Ռեդիսը վերածվում է դդմի։
• repl-ping-slave-period 5
  Այս ժամանակահատվածից հետո մենք կսկսենք անհանգստանալ, որ վարպետը խափանվել է, և ժամանակն է իրականացնել ձախողման ընթացակարգը:
  Դուք ստիպված կլինեք ձեռքով հավասարակշռություն գտնել կեղծ պոզիտիվների և ձախողման առաջացման միջև: Մեր պրակտիկայում սա 5 վայրկյան է:
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Մենք կարող ենք հենց այդքան տվյալներ պահել բուֆերում՝ ձախողված կրկնօրինակի համար: Եթե ​​բուֆերը սպառվում է, դուք պետք է ամբողջությամբ համաժամանակացնեք:
  Պրակտիկան հուշում է, որ ավելի լավ է ավելի բարձր արժեք սահմանել: Կան բազմաթիվ պատճառներ, թե ինչու կրկնօրինակը կարող է սկսել ուշանալ: Եթե ​​այն ուշանում է, ապա, ամենայն հավանականությամբ, ձեր վարպետն արդեն պայքարում է հաղթահարելու համար, և ամբողջական համաժամացումը կլինի վերջին կաթիլը:
• առավելագույն հաճախորդներ 10000
  Մեկանգամյա հաճախորդների առավելագույն քանակը:
  Մեր փորձով ավելի լավ է ավելի բարձր արժեք սահմանել: Redis-ը լավ է կառավարում 10 հազար կապ: Պարզապես համոզվեք, որ համակարգում բավականաչափ վարդակներ կան:
• maxmemory-policy volatile-ttl
  Կանոնը, որով ստեղները ջնջվում են, երբ հասնում է հասանելի հիշողության սահմանաչափը:
  Այստեղ կարևորը ոչ թե կանոնն է, այլ այն, թե ինչպես դա տեղի կունենա: Redis-ին կարելի է գովաբանել նորմալ աշխատելու ունակության համար, երբ հասնում է հիշողության սահմանաչափը:

RDB և AOF խնդիրներ

Չնայած Redis-ն ինքն է պահում ամբողջ տեղեկատվությունը RAM-ում, սակայն կա նաև տվյալների սկավառակի վրա պահելու մեխանիզմ: Ավելի ճիշտ՝ երեք մեխանիզմ.

• RDB-snapshot - բոլոր տվյալների ամբողջական պատկերը: Սահմանեք SAVE XY կոնֆիգուրացիան և կարդացեք «Պահպանեք բոլոր տվյալների ամբողջական պատկերը յուրաքանչյուր X վայրկյանում, եթե առնվազն Y ստեղները փոխվել են»:
• Միայն հավելվածի ֆայլ - գործողությունների ցանկ՝ ըստ դրանց կատարման: Յուրաքանչյուր X վայրկյան կամ յուրաքանչյուր Y գործողություն ֆայլին ավելացնում է նոր մուտքային գործողություններ:
• RDB-ն և AOF-ը նախորդ երկուսի համակցությունն են:

Բոլոր մեթոդներն ունեն իրենց առավելություններն ու թերությունները, ես բոլորին չեմ թվարկի, պարզապես ուշադրություն կդարձնեմ կետերի վրա, որոնք, իմ կարծիքով, ակնհայտ չեն։

Նախ, RDB-ի լուսանկարը պահպանելու համար անհրաժեշտ է զանգահարել FORK: Եթե ​​շատ տվյալներ կան, սա կարող է կախել ամբողջ Redis-ը մի քանի միլիվայրկյանից վայրկյանի ընթացքում: Բացի այդ, համակարգը պետք է հիշողություն հատկացնի նման նկարի համար, ինչը հանգեցնում է տրամաբանական մեքենայի վրա RAM-ի կրկնակի մատակարարման անհրաժեշտության. այն.

Երկրորդ, խնդիրներ կան մասնակի համաժամացման հետ: AOF ռեժիմում, երբ ստրուկը նորից միացված է, մասնակի համաժամացման փոխարեն կարող է կատարվել ամբողջական համաժամացում: Ինչու է դա տեղի ունենում, ես չկարողացա հասկանալ: Բայց սա արժե հիշել.

Այս երկու կետերն արդեն ստիպում են մեզ մտածել, թե արդյոք մեզ իսկապես անհրաժեշտ են այս տվյալները սկավառակի վրա, եթե ամեն ինչ արդեն կրկնօրինակված է ստրուկների կողմից: Տվյալները կարող են կորցնել միայն այն դեպքում, եթե բոլոր ստրուկները ձախողվեն, և սա «կրակ DC-ում» մակարդակի խնդիր է: Որպես փոխզիջում, դուք կարող եք առաջարկել տվյալները պահպանել միայն ստրուկների վրա, բայց այս դեպքում դուք պետք է համոզվեք, որ այս ստրուկները երբեք տեր չեն դառնա աղետի վերականգնման ժամանակ (դրա կազմաձևում կա ստրուկի առաջնահերթության կարգավորում): Մեզ համար, յուրաքանչյուր կոնկրետ դեպքում մենք մտածում ենք, թե արդյոք անհրաժեշտ է տվյալները պահել սկավառակի վրա, և ամենից հաճախ պատասխանը «ոչ» է:

Ամփոփում

Եզրափակելով, հուսով եմ, որ կարողացա ընդհանուր պատկերացում կազմել այն մասին, թե ինչպես է աշխատում redis-cluster-ը նրանց համար, ովքեր ընդհանրապես չեն լսել դրա մասին, ինչպես նաև ուշադրություն հրավիրեցի որոշ ոչ ակնհայտ կետերի վրա, ովքեր օգտագործում էին այն: երկար ժամանակով.
Շնորհակալություն ձեր ժամանակի համար և, ինչպես միշտ, թեմայի վերաբերյալ մեկնաբանությունները ողջունելի են:

Source: www.habr.com