В վերջին հոդվածը մենք ուսումնասիրեցինք RabbitMQ կլաստերավորումը սխալների հանդուրժողականության և բարձր հասանելիության համար: Հիմա եկեք խորանանք Ապաչի Կաֆկայի մեջ:

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

Բրինձ. 1. Չորս բաժինը բաշխված է երեք բրոքերների միջև

Բոլոր կարդալու և գրելու հարցումները գնում են առաջնորդին: Հետևորդները պարբերաբար հարցումներ են ուղարկում առաջնորդին՝ վերջին հաղորդագրությունները ստանալու համար: Սպառողները երբեք չեն դիմում հետևորդների, վերջիններս գոյություն ունեն միայն ավելորդության և սխալների հանդուրժողականության համար:

Բաժանման ձախողում

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

Բրոքեր 3-ը լքում է ցանցը, և բրոքեր 2-ում ընտրվում է նոր ղեկավար 2-րդ բաժնի համար:

Բրինձ. 2. Բրոքեր 3-ը մահանում է, և նրա հետևորդը բրոքեր 2-ում ընտրվում է որպես բաժանման 2-ի նոր ղեկավար

Այնուհետև բրոքեր 1-ը հեռանում է, իսկ 1-ին բաժինը նույնպես կորցնում է իր առաջնորդին, որի դերը անցնում է բրոքեր 2-ին:

Բրինձ. 3. Մնացել է մեկ բրոքեր։ Բոլոր առաջնորդները մեկ բրոքերի վրա են՝ զրոյական ավելորդությամբ

Երբ բրոքեր 1-ը վերադառնում է առցանց, այն ավելացնում է չորս հետևորդ՝ ապահովելով որոշակի ավելորդություն յուրաքանչյուր բաժանման համար: Բայց բոլոր առաջատարները դեռևս մնացին բրոքեր 2-ում:

Բրինձ. 4. Առաջնորդները մնում են բրոքեր 2

Երբ բրոքեր 3-ը հայտնվում է, մենք վերադառնում ենք յուրաքանչյուր բաժանման երեք կրկնօրինակի: Բայց բոլոր առաջատարները դեռ բրոքեր 2-ի վրա են:

Բրինձ. 5. Բրոքերների 1-ին և 3-ի վերականգնումից հետո առաջատարների անհավասարակշիռ տեղաբաշխում

Կաֆկան RabbitMQ-ից ավելի լավ առաջնորդների հավասարակշռման գործիք ունի: Այնտեղ դուք պետք է օգտագործեիք երրորդ կողմի պլագին կամ սցենար, որը փոխեց հիմնական հանգույցը տեղափոխելու քաղաքականությունը՝ նվազեցնելով ավելորդությունը միգրացիայի ընթացքում: Բացի այդ, մեծ հերթերի համար մենք պետք է ընդունեինք անհասանելիությունը համաժամացման ժամանակ:

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

Դա շտկելու համար Կաֆկան առաջարկում է երկու տարբերակ.

• Տարբերակ auto.leader.rebalance.enable=true թույլ է տալիս վերահսկիչ հանգույցին ավտոմատ կերպով վերանշանակել առաջնորդները նախընտրելի կրկնօրինակներին և դրանով իսկ վերականգնել միասնական բաշխումը:
• Ադմինիստրատորը կարող է գործարկել սցենարը kafka-preferred-replica-election.sh ձեռքով վերաբաշխման համար:

Բրինձ. 6. Replicas հետո rebalancing

Սա ձախողման պարզեցված տարբերակ էր, բայց իրականությունն ավելի բարդ է, թեև այստեղ շատ բարդ բան չկա։ Ամեն ինչ հանգում է սինխրոնիզացված կրկնօրինակներին (In-Sync Replicas, ISR):

Սինքրոնացված կրկնօրինակներ (ISR)

ISR-ը բաժանման կրկնօրինակների մի շարք է, որը համարվում է «համաժամեցված» (in-sync): Լիդեր կա, բայց հետևորդներ կարող են չլինել։ Հետևորդը համարվում է համաժամանակացված, եթե նա կատարել է առաջնորդի բոլոր հաղորդագրությունների ճշգրիտ պատճենները մինչև ընդմիջման ժամկետի ավարտը: replica.lag.time.max.ms.

Հետևորդը հեռացվում է ISR հավաքածուից, եթե նա՝

• ինտերվալի համար ընտրելու հարցում չի կատարել replica.lag.time.max.ms (ենթադրվում է մահացած)
• չհաջողվեց թարմացնել ընդմիջման ընթացքում replica.lag.time.max.ms (համարվում է դանդաղ)

Հետևորդները նմուշառման հարցումներ են կատարում ընդմիջումով replica.fetch.wait.max.ms, որը կանխադրված է 500ms:

ISR-ի նպատակը հստակ բացատրելու համար մենք պետք է նայենք արտադրողի հաստատումներին և ձախողման որոշ սցենարներին: Արտադրողները կարող են ընտրել, երբ բրոքերը հաստատում է ուղարկում.

• acks=0, հաստատումը չի ուղարկվել
• acks=1, հաստատումն ուղարկվում է այն բանից հետո, երբ ղեկավարը հաղորդագրություն է գրել իր տեղական գրանցամատյանին
• acks=all, հաստատումն ուղարկվում է այն բանից հետո, երբ ISR-ի բոլոր կրկնօրինակները հաղորդագրությունը գրեն տեղական տեղեկամատյաններում

Կաֆկայի տերմինաբանությամբ, եթե ISR-ն պահպանել է հաղորդագրություն, այն «պարտավորվում է»: Acks=all-ը ամենաանվտանգ տարբերակն է, բայց նաև ավելացնում է լրացուցիչ ուշացում: Դիտարկենք ձախողման երկու օրինակ և ինչպես են տարբեր «acks» տարբերակները փոխազդում ISR հայեցակարգի հետ:

Acks=1 և ISR

Այս օրինակում մենք կտեսնենք, որ եթե առաջնորդը չի սպասում, որ բոլոր հետևորդներից յուրաքանչյուր հաղորդագրություն պահվի, ապա տվյալների կորուստը հնարավոր է, եթե առաջնորդը ձախողվի: Դեպի չհամաժամացված հետևորդ նավարկելը կարող է միացվել կամ անջատվել՝ կարգավորելով unclean.leader.election.enable.

Այս օրինակում արտադրողն ունի acks=1 արժեքը: Բաժինը բաշխված է բոլոր երեք բրոքերների վրա: Broker 3-ը հետ է մնում, այն ութ վայրկյան առաջ սինխրոնիզացվել է առաջատարի հետ և այժմ հետ է մնում 7456 հաղորդագրությունից: Բրոքեր 1-ը զիջում էր ընդամենը մեկ վայրկյան: Մեր պրոդյուսերը հաղորդագրություն է ուղարկում և արագ պատասխան է ստանում՝ առանց դանդաղ կամ մեռած հետևորդների գերբեռնվածության, որին առաջնորդը չի սպասում:

Բրինձ. 7. ISR երեք կրկնօրինակներով

Բրոքեր 2-ը ձախողվում է, և արտադրողը ստանում է միացման սխալ: Այն բանից հետո, երբ ղեկավարությունը անցնում է բրոքեր 1-ին, մենք կորցնում ենք 123 հաղորդագրություն: Բրոքեր 1-ի հետևորդը եղել է ISR-ի մի մասը, բայց ամբողջությամբ չի համաժամանակացվել առաջատարի հետ, երբ այն ընկել է:

Բրինձ. 8. Հաղորդագրությունները կորչում են, երբ այն խափանում է

Կոնֆիգուրացիայի մեջ bootstrap.servers Արտադրողը ցուցակում ունի մի քանի բրոքերներ և կարող է հարցնել մեկ այլ բրոքերի, թե ով է նոր բաժնի ղեկավարը: Այնուհետև այն կապ է հաստատում բրոքեր 1-ի հետ և շարունակում է հաղորդագրություններ ուղարկել:

Բրինձ. 9. Հաղորդագրությունների ուղարկումը վերսկսվում է կարճ ընդմիջումից հետո

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

Բրինձ. 10. Բրոքեր 3-ի հետևորդը հեռացվում է ISR-ից

Բրոքեր 1-ը իջնում ​​է, իսկ առաջնորդի դերը անցնում է բրոքեր 3-ին՝ 15286 հաղորդագրությունների կորստով: Արտադրողը ստանում է միացման սխալի հաղորդագրություն: ISR-ից դուրս առաջնորդի անցումը հնարավոր էր միայն պայմանավորվածության շնորհիվ unclean.leader.election.enable=true. Եթե ​​այն տեղադրված է սուտ, ապա անցումը տեղի չի ունենա, և բոլոր կարդալու և գրելու հարցումները կմերժվեն: Այս դեպքում մենք սպասում ենք, որ բրոքեր 1-ը վերադառնա իր անձեռնմխելի տվյալներով կրկնօրինակում, որը կրկին կստանձնի ղեկավարությունը:

Բրինձ. 11. Բրոքեր 1-ն ընկնում է. Երբ ձախողում է տեղի ունենում, մեծ թվով հաղորդագրություններ կորչում են

Պրոդյուսերը կապ է հաստատում վերջին բրոքերի հետ և տեսնում, որ նա այժմ բաժնի ղեկավարն է։ Նա սկսում է հաղորդագրություններ ուղարկել բրոքեր 3-ին:

Բրինձ. 12. Կարճ ընդմիջումից հետո հաղորդագրությունները կրկին ուղարկվում են բաժին 0

Մենք տեսանք, որ, բացի նոր կապեր հաստատելու և նոր առաջնորդ փնտրելու կարճ ընդհատումներից, արտադրողն անընդհատ հաղորդագրություններ էր ուղարկում։ Այս կոնֆիգուրացիան ապահովում է հասանելիությունը հետևողականության (տվյալների անվտանգության) հաշվին: Կաֆկան կորցրեց հազարավոր հաղորդագրություններ, բայց շարունակեց ընդունել նոր գրություններ:

Acks=բոլորը և ISR

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

Բրինձ. 13. ISR երեք կրկնօրինակներով: Մեկը դանդաղ է, ինչը հանգեցնում է ձայնագրման հետաձգմանը

Չորս վայրկյան հավելյալ ուշացումից հետո բրոքեր 2-ը ակ է ուղարկում: Բոլոր կրկնօրինակներն այժմ լիովին թարմացվել են:

Բրինձ. 14. Բոլոր կրկնօրինակները պահպանում են հաղորդագրությունները և ուղարկում հաղորդագրություններ

Բրոքեր 3-ն այժմ ավելի հետ է մնում և հեռացվում է ISR-ից: Լատենտությունը զգալիորեն կրճատվել է, քանի որ ISR-ում դանդաղ կրկնօրինակներ չեն մնացել: Բրոքեր 2-ն այժմ սպասում է միայն բրոքեր 1-ին, և նրա միջին ուշացումը կազմում է 500 ms:

Բրինձ. 15. Բրոքեր 3-ի կրկնօրինակը հանվում է ISR-ից

Այնուհետև բրոքեր 2-ն ընկնում է, և ղեկավարությունն անցնում է բրոքեր 1-ին առանց հաղորդագրությունների կորստի:

Բրինձ. 16. Բրոքեր 2-ն ընկնում է

Արտադրողը գտնում է նոր ղեկավար և սկսում է նրան հաղորդագրություններ ուղարկել։ Լատենտությունն ավելի է կրճատվում, քանի որ ISR-ն այժմ բաղկացած է մեկ կրկնօրինակից: Հետևաբար տարբերակը ակս=բոլոր ավելորդություն չի ավելացնում:

Բրինձ. 17. Բրոքեր 1-ի կրկնօրինակը առաջատար է առանց հաղորդագրությունների կորստի

Այնուհետև բրոքեր 1-ը խափանում է, և առաջատարը գնում է բրոքեր 3-ին՝ 14238 հաղորդագրությունների կորստով:

Բրինձ. 18. Բրոքեր 1-ը մահանում է, և ղեկավարության անցումը անմաքուր կարգավորումներով հանգեցնում է տվյալների մեծ կորստի

Մենք չկարողացանք տեղադրել տարբերակը unclean.leader.election.enable իմաստի մեջ ճիշտ. Լռելյայն հավասար է սուտ. Կարգավորումներ ակս=բոլոր с unclean.leader.election.enable=true ապահովում է հասանելիություն տվյալների որոշ լրացուցիչ անվտանգության հետ: Բայց ինչպես տեսնում եք, մենք դեռ կարող ենք կորցնել հաղորդագրությունները:

Բայց ի՞նչ, եթե մենք ցանկանում ենք բարձրացնել տվյալների անվտանգությունը: Դուք կարող եք տեղադրել unclean.leader.election.enable = կեղծ, բայց դա անպայման չի պաշտպանի մեզ տվյալների կորստից: Եթե ​​առաջատարը ծանր ընկավ և իր հետ վերցրեց տվյալները, ապա հաղորդագրությունները դեռ կորչում են, գումարած հասանելիությունը կորչում է, մինչև ադմինիստրատորը վերականգնի իրավիճակը:

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

Acks=all, min.insync.replicas և ISR

Թեմայի կոնֆիգուրացիայով min.insync.replicas Մենք բարձրացնում ենք տվյալների անվտանգության մակարդակը։ Եկեք նորից անցնենք նախորդ սցենարի վերջին մասը, բայց այս անգամ՝ դրանով min.insync.replicas=2.

Այսպիսով, բրոքեր 2-ն ունի կրկնօրինակի առաջնորդ, և բրոքեր 3-ի հետևորդը հեռացվում է ISR-ից:

Բրինձ. 19. ISR երկու կրկնօրինակներից

Բրոքեր 2-ն ընկնում է, և ղեկավարությունը անցնում է բրոքեր 1-ին առանց հաղորդագրությունների կորստի: Սակայն այժմ ISR-ն բաղկացած է միայն մեկ կրկնօրինակից: Սա չի համապատասխանում գրառումներ ստանալու նվազագույն թվին, և, հետևաբար, բրոքերը պատասխանում է գրելու փորձին սխալմամբ NotEnoughReplicas.

Բրինձ. 20. ISR-ների թիվը մեկով ցածր է min.insync.replicas-ում նշվածից

Այս կոնֆիգուրացիան զոհաբերում է հասանելիությունը հետևողականության համար: Հաղորդագրությունն ընդունելուց առաջ մենք համոզվում ենք, որ այն գրված է առնվազն երկու կրկնօրինակների վրա: Սա արտադրողին ավելի մեծ վստահություն է տալիս: Այստեղ հաղորդագրության կորուստը հնարավոր է միայն այն դեպքում, եթե երկու կրկնօրինակները միաժամանակ ձախողվեն կարճ ընդմիջումով, մինչև հաղորդագրությունը կրկնօրինակվի լրացուցիչ հետևորդին, ինչը քիչ հավանական է: Բայց եթե դուք սուպեր պարանոյիկ եք, կարող եք կրկնօրինակման գործակիցը սահմանել 5, և min.insync.replicas 3-ով. Այստեղ երեք բրոքերներ պետք է միաժամանակ ընկնեն ռեկորդը կորցնելու համար: Իհարկե, դուք վճարում եք այս հուսալիության համար լրացուցիչ ուշացումով:

Երբ հասանելիությունը անհրաժեշտ է տվյալների անվտանգության համար

Ինչպես նաեւ գործ RabbitMQ-ով, երբեմն հասանելիությունը անհրաժեշտ է տվյալների անվտանգության համար։ Ահա թե ինչի մասին պետք է մտածել.

• Կարո՞ղ է հրատարակիչը պարզապես սխալ վերադարձնել և թույլ տալ, որ վերին հոսքի ծառայությունը կամ օգտվողը նորից փորձի ավելի ուշ:
• Կարո՞ղ է հրատարակիչը պահել հաղորդագրությունը տեղական կամ տվյալների բազայում՝ ավելի ուշ նորից փորձելու համար:

Եթե ​​պատասխանը ոչ է, ապա հասանելիության օպտիմալացումը բարելավում է տվյալների անվտանգությունը: Դուք ավելի քիչ տվյալներ կկորցնեք, եթե չձայնագրելու փոխարեն ընտրեք հասանելիությունը: Այսպիսով, ամեն ինչ հանգում է հավասարակշռություն գտնելուն, իսկ որոշումը կախված է կոնկրետ իրավիճակից։

ISR-ի իմաստը

ISR-ների մի շարք թույլ է տալիս ընտրել տվյալների անվտանգության և հետաձգման օպտիմալ հավասարակշռությունը: Օրինակ՝ ապահովել հասանելիությունը կրկնօրինակների մեծամասնության ձախողման դեպքում՝ նվազագույնի հասցնելով մեռած կամ դանդաղ կրկնօրինակների ազդեցությունը հետաձգման առումով:

Մենք ինքներս ենք ընտրում իմաստը replica.lag.time.max.ms ըստ ձեր կարիքների: Ըստ էության, այս պարամետրը նշանակում է, թե որքան ուշացում ենք մենք պատրաստ ընդունել, երբ ակս=բոլոր. Լռելյայն արժեքը տասը վայրկյան է: Եթե ​​սա շատ երկար է ձեզ համար, կարող եք կրճատել այն: Այնուհետև ISR-ում փոփոխությունների հաճախականությունը կավելանա, քանի որ հետևորդները կհեռացվեն և ավելի հաճախ կավելացվեն:

RabbitMQ-ը պարզապես հայելիների մի շարք է, որոնք պետք է կրկնօրինակվեն: Դանդաղ հայելիները ներմուծում են լրացուցիչ ուշացում, իսկ մեռած հայելիները կարող են սպասել, մինչև որ փաթեթները, որոնք ստուգում են յուրաքանչյուր հանգույցի առկայությունը (զուտ տիզ) արձագանքեն: ISR-ը հետաքրքիր միջոց է այս հետաձգման խնդիրներից խուսափելու համար: Բայց մենք ռիսկի ենք դիմում կորցնելու ավելորդությունը, քանի որ ISR-ը կարող է միայն կրճատվել մինչև առաջատարը: Այս ռիսկից խուսափելու համար օգտագործեք կարգավորումը min.insync.replicas.

Հաճախորդի կապի երաշխիք

Պարամետրերում bootstrap.servers արտադրողը և սպառողը կարող են նշել բազմաթիվ բրոքերներ հաճախորդներին միացնելու համար: Գաղափարն այն է, որ երբ մի հանգույց իջնում ​​է, մնում են մի քանի պահեստայիններ, որոնց հետ հաճախորդը կարող է բացել կապը: Սրանք անպայմանորեն հատվածի առաջատարներ չեն, այլ պարզապես ցատկահարթակ նախնական բեռնման համար: Հաճախորդը կարող է հարցնել նրանց, թե որ հանգույցն է հյուրընկալում կարդալ/գրել բաժանման առաջատարը:

RabbitMQ-ում հաճախորդները կարող են միանալ ցանկացած հանգույցի, և ներքին երթուղավորումը հարցումն ուղարկում է այնտեղ, որտեղ այն պետք է գնա: Սա նշանակում է, որ RabbitMQ-ի դիմաց կարող եք տեղադրել բեռի հավասարակշռող սարք: Կաֆկան հաճախորդներից պահանջում է միանալ այն հանգույցին, որը հյուրընկալում է համապատասխան բաժանման առաջնորդին: Նման իրավիճակում դուք չեք կարող տեղադրել բեռի հավասարակշռող սարք: Ցուցակ bootstrap.servers Շատ կարևոր է, որ հաճախորդները կարողանան մուտք գործել և գտնել ճիշտ հանգույցները ձախողումից հետո:

Կաֆկայի կոնսենսուսի ճարտարապետություն

Մինչ այժմ մենք չենք դիտարկել, թե ինչպես է կլաստերը իմանում բրոքերի անկման մասին և ինչպես է ընտրվում նոր առաջնորդ։ Հասկանալու համար, թե ինչպես է Կաֆկան աշխատում ցանցային միջնորմների հետ, նախ պետք է հասկանալ կոնսենսուսի ճարտարապետությունը:

Յուրաքանչյուր Kafka կլաստեր տեղակայված է Zookeeper կլաստերի հետ միասին, որը բաշխված կոնսենսուսային ծառայություն է, որը թույլ է տալիս համակարգին հասնել կոնսենսուսի որոշակի վիճակի վերաբերյալ՝ առաջնահերթություն տալով հետևողականությանը, քան հասանելիությանը: Կարդալու և գրելու գործողությունները հաստատելու համար պահանջվում է Zookeeper հանգույցների մեծամասնության համաձայնությունը:

Zookeeper-ը պահպանում է կլաստերի վիճակը.

• Թեմաների ցանկ, բաժիններ, կոնֆիգուրացիա, ընթացիկ առաջնորդի կրկնօրինակներ, նախընտրելի կրկնօրինակներ:
• Կլաստերի անդամներ. Յուրաքանչյուր բրոքեր կապում է Zookeeper կլաստերին: Եթե ​​այն չի ստանա պինգ նշված ժամանակահատվածում, ապա Zookeeper-ը գրանցում է միջնորդին որպես անհասանելի:
• Ընտրելով հիմնական և պահեստային հանգույցները կարգավորիչի համար:

Վերահսկիչ հանգույցը Կաֆկայի բրոքերներից մեկն է, որը պատասխանատու է կրկնօրինակների առաջնորդների ընտրության համար: Zookeeper-ը վերահսկիչին ծանուցումներ է ուղարկում կլաստերի անդամակցության և թեմաների փոփոխությունների մասին, և վերահսկիչը պետք է գործի այդ փոփոխություններին համապատասխան:

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

Յուրաքանչյուր հատվածի վերահսկիչի համար.

• թարմացնում է Zookeeper-ում տեղեկատվությունը ISR-ի և առաջնորդի մասին.
• Ուղարկում է LeaderAndISRCommand յուրաքանչյուր բրոքերի, որը հյուրընկալում է այս բաժանման կրկնօրինակը՝ տեղեկացնելով բրոքերներին ISR-ի և առաջատարի մասին:

Երբ առաջատարի հետ բրոքերն ընկնում է, Zookeeper-ը ծանուցում է ուղարկում վերահսկիչին, և նա ընտրում է նոր ղեկավար: Կրկին, վերահսկիչը նախ թարմացնում է Zookeeper-ը, այնուհետև հրաման է ուղարկում յուրաքանչյուր բրոքերի՝ տեղեկացնելով ղեկավարության փոփոխության մասին:

Յուրաքանչյուր ղեկավար պատասխանատու է ISR-ների հավաքագրման համար: Կարգավորումներ replica.lag.time.max.ms որոշում է, թե ովքեր են մտնելու այնտեղ: Երբ ISR-ը փոխվում է, առաջնորդը նոր տեղեկատվություն է փոխանցում Zookeeper-ին:

Zookeeper-ը միշտ տեղեկացված է ցանկացած փոփոխության մասին, որպեսզի ձախողման դեպքում ղեկավարությունը սահուն անցում կատարի նոր ղեկավարի:

Բրինձ. 21. Կաֆկա կոնսենսուս

Կրկնօրինակման արձանագրություն

Կրկնօրինակման մանրամասները հասկանալն օգնում է ձեզ ավելի լավ հասկանալ տվյալների կորստի հնարավոր սցենարները:

Ընտրանքային հարցումներ, Log End Offset (LEO) և Highwater Mark (HW)

Մենք համարեցինք, որ հետևորդները պարբերաբար բեռնման հարցումներ են ուղարկում առաջնորդին։ Լռելյայն ինտերվալը 500 մս է: Սա RabbitMQ-ից տարբերվում է նրանով, որ RabbitMQ-ում կրկնօրինակումը նախաձեռնվում է ոչ թե հերթի հայելու, այլ վարպետի կողմից: Վարպետը փոփոխություններ է մղում հայելիների վրա:

Առաջնորդը և բոլոր հետևորդները պահպանում են Log End Offset (LEO) և Highwater (HW) պիտակը: LEO նշանը պահպանում է վերջին հաղորդագրության օֆսեթը տեղական կրկնօրինակում, իսկ HW-ն պահում է վերջին հանձնման օֆսեթը: Հիշեք, որ ստանձնման կարգավիճակի համար հաղորդագրությունը պետք է պահպանվի բոլոր ISR կրկնօրինակներում: Սա նշանակում է, որ LEO-ն սովորաբար փոքր-ինչ առաջ է HW-ից:

Երբ առաջնորդը հաղորդագրություն է ստանում, այն պահում է տեղում: Հետևորդը կատարում է խնդրանք՝ փոխանցելով իր LEO-ին: Առաջնորդն այնուհետև ուղարկում է հաղորդագրությունների փաթեթ՝ սկսած այս LEO-ից և նաև փոխանցում է ընթացիկ HW-ն: Երբ առաջնորդը ստանում է տեղեկատվություն, որ բոլոր կրկնօրինակները պահել են հաղորդագրությունը տվյալ օֆսեթում, այն տեղափոխում է HW նշանը: Միայն առաջնորդը կարող է տեղափոխել HW-ն, և այդպիսով բոլոր հետևորդները կիմանան իրենց խնդրանքի պատասխանների ներկայիս արժեքը: Սա նշանակում է, որ հետևորդները կարող են հետ մնալ առաջատարից և՛ հաղորդագրությունների, և՛ HW գիտելիքներով: Սպառողները հաղորդագրություններ են ստանում միայն մինչև ընթացիկ HW:

Նկատի ունեցեք, որ «համառ» նշանակում է գրված հիշողության մեջ, ոչ թե սկավառակի վրա: Կատարման համար Կաֆկան սինխրոնիզացվում է սկավառակի հետ որոշակի ընդմիջումով: RabbitMQ-ն նույնպես ունի նման ընդմիջում, սակայն այն հաստատող փաստաթուղթ կուղարկի հրատարակչին միայն այն բանից հետո, երբ վարպետը և բոլոր հայելիները կգրեն հաղորդագրությունը սկավառակի վրա: Kafka-ի մշակողները, կատարողական նկատառումներից ելնելով, որոշեցին հաղորդագրություն ուղարկել հենց հաղորդագրությունը հիշողության մեջ գրվել: Կաֆկան խաղադրույք է կատարում, որ ավելորդությունը փոխհատուցում է միայն հաստատված հաղորդագրությունները հիշողության մեջ հակիրճ պահելու վտանգը:

Առաջնորդի ձախողում

Երբ առաջնորդը ընկնում է, Zookeeper-ը տեղեկացնում է վերահսկիչին, և նա ընտրում է նոր առաջնորդի կրկնօրինակը: Նոր ղեկավարը նոր HW նշան է դնում իր LEO-ի համաձայն: Այնուհետև հետևորդները տեղեկություններ են ստանում նոր առաջնորդի մասին: Կախված Կաֆկայի տարբերակից, հետևորդը կընտրի երկու սցենարներից մեկը.

1. Այն կկտրի տեղական գրանցամատյանը հայտնի HW-ին և նոր ղեկավարին հարցում կուղարկի այս նշանից հետո հաղորդագրությունների համար:
2. Առաջնորդին հարցում կուղարկի պարզելու HW-ն այն ժամանակ, երբ նա ընտրվել է ղեկավար, և այնուհետև կտրել տեղեկամատյանը այս օֆսեթին: Այնուհետև այն կսկսի կատարել առբերման պարբերական հարցումներ՝ սկսած այս օֆսեթից:

Հետևորդին կարող է անհրաժեշտ լինել կրճատել գրանցամատյանը հետևյալ պատճառներով.

• Երբ առաջնորդը ձախողվում է, Zookeeper-ում գրանցված ISR հավաքածուի առաջին հետևորդը հաղթում է ընտրություններում և դառնում առաջատար: ISR-ի բոլոր հետևորդները, թեև համարվում են «համաժամեցված», հնարավոր է, որ նախկին առաջնորդից չեն ստացել բոլոր հաղորդագրությունների պատճենները: Լիովին հնարավոր է, որ ներկայացված հետևորդը չունի ամենաարդիական պատճենը: Կաֆկան վստահեցնում է, որ կրկնօրինակների միջև տարաձայնություններ չկան: Այսպիսով, անհամապատասխանություններից խուսափելու համար յուրաքանչյուր հետևորդ պետք է կրճատի իր գրանցամատյանը նոր առաջնորդի HW արժեքին ընտրվելու պահին: Սա ևս մեկ պատճառ է, թե ինչու է կարգավորումը ակս=բոլոր այնքան կարևոր է հետևողականության համար:
• Հաղորդագրությունները պարբերաբար գրվում են սկավառակի վրա: Եթե ​​բոլոր կլաստերային հանգույցները միաժամանակ ձախողվեն, ապա տարբեր օֆսեթներով կրկնօրինակները կպահվեն սկավառակների վրա: Հնարավոր է, որ երբ բրոքերները վերադառնան առցանց, նոր առաջնորդը, ով ընտրվում է, մնա իր հետևորդների հետևում, քանի որ նա պահվել է սկավառակի վրա մյուսներից առաջ:

Վերամիավորում կլաստերի հետ

Կլաստերին նորից միանալիս կրկնօրինակներն անում են նույնը, ինչ առաջնորդի ձախողման դեպքում. նրանք ստուգում են առաջնորդի կրկնօրինակը և կտրում են իրենց գրանցամատյանը HW-ին (ընտրության պահին): Համեմատության համար, RabbitMQ հավասարապես վերամիավորված հանգույցներին վերաբերվում է որպես բոլորովին նոր: Երկու դեպքում էլ բրոքերը հրաժարվում է գոյություն ունեցող ցանկացած վիճակից: Եթե ​​օգտագործվում է ավտոմատ համաժամացում, ապա վարպետը պետք է վերարտադրի բացարձակապես ողջ ընթացիկ բովանդակությունը նոր հայելու մեջ «թող ողջ աշխարհը սպասի» մեթոդով: Վարպետը չի ընդունում որևէ կարդալու կամ գրելու գործողություն այս գործողության ընթացքում: Այս մոտեցումը մեծ հերթերում խնդիրներ է ստեղծում:

Kafka-ն բաշխված տեղեկամատյան է, և ընդհանուր առմամբ այն ավելի շատ հաղորդագրություններ է պահում, քան RabbitMQ հերթը, որտեղ տվյալները կարդալուց հետո հեռացվում են հերթից: Ակտիվ հերթերը պետք է մնան համեմատաբար փոքր: Բայց Կաֆկան գերան է՝ իր պահպանման քաղաքականությամբ, որը կարող է օրեր կամ շաբաթներ սահմանել: Հերթի արգելափակման և ամբողջական համաժամացման մոտեցումը բացարձակապես անընդունելի է բաշխված գրանցամատյանի համար: Փոխարենը, Կաֆկայի հետևորդները պարզապես կրճատում են իրենց գրանցամատյանը առաջնորդի HW-ին (նրա ընտրվելու պահին), եթե նրանց օրինակը առաջ է առաջնորդից: Ավելի հավանական դեպքում, երբ հետևորդը ետևում է, նա պարզապես սկսում է առբերման հարցումներ կատարել՝ սկսած իր ներկայիս LEO-ից:

Նոր կամ նորից միացած հետևորդները սկսում են ISR-ից դուրս և չեն մասնակցում պարտավորություններին: Նրանք պարզապես աշխատում են խմբի կողքին՝ ստանալով հաղորդագրություններ այնքան արագ, որքան կարող են, մինչև նրանք հասնեն առաջնորդին և մտնեն ISR: Չկա կողպեք և կարիք չկա դեն նետել ձեր բոլոր տվյալները:

Կապի կորուստ

Kafka-ն ավելի շատ բաղադրիչներ ունի, քան RabbitMQ-ն, ուստի այն ունի վարքագծերի ավելի բարդ շարք, երբ կլաստերն անջատվում է: Բայց Կաֆկան ի սկզբանե նախատեսված էր կլաստերների համար, ուստի լուծումները շատ լավ մտածված են:

Ստորև բերված են միացման ձախողման մի քանի սցենար.

• Սցենար 1. Հետևորդը չի տեսնում առաջնորդին, բայց դեռ տեսնում է Կենդանաբանական այգու պահապանին:
• Սցենար 2. Առաջնորդը չի տեսնում որևէ հետևորդ, բայց դեռ տեսնում է Zookeeper-ը:
• Սցենար 3. Հետևորդը տեսնում է առաջնորդին, բայց չի տեսնում Կենդանաբանական այգու պահապանին:
• Սցենար 4. Առաջնորդը տեսնում է հետևորդներին, բայց չի տեսնում Կենդանաբանական այգու պահապանին:
• Սցենար 5. Հետևորդը լիովին անջատված է ինչպես Կաֆկայի մյուս հանգույցներից, այնպես էլ Zookeeper-ից:
• Սցենար 6. Առաջնորդը լիովին անջատված է ինչպես Կաֆկայի մյուս հանգույցներից, այնպես էլ Zookeeper-ից:
• Սցենար 7. Kafka կարգավորիչ հանգույցը չի կարող տեսնել մեկ այլ Kafka հանգույց:
• Սցենար 8. Kafka-ի վերահսկիչը չի տեսնում Zookeeper-ը:

Յուրաքանչյուր սցենար ունի իր վարքագիծը:

Սցենար 1. Հետևորդը չի տեսնում առաջնորդին, բայց դեռ տեսնում է Zookeeper-ին

Բրինձ. 22. Սցենար 1. երեք կրկնօրինակների ISR

Միացման ձախողումը բաժանում է բրոքեր 3-ը 1-ին և 2-րդ բրոքերներից, բայց ոչ Zookeeper-ից: Բրոքեր 3-ն այլևս չի կարող ուղարկել առբերման հարցումներ: Ժամանակն անցնելուց հետո replica.lag.time.max.ms այն հեռացվում է ISR-ից և չի մասնակցում հաղորդագրությունների հանձնառություններին: Կապը վերականգնվելուց հետո այն կվերսկսի բեռնել հարցումները և կմիանա ISR-ին, երբ հասնի առաջատարին: Zookeeper-ը կշարունակի պինգեր ստանալ և ենթադրել, որ բրոքերը ողջ է և առողջ:

Բրինձ. 23. Սցենար 1. Բրոքերը հեռացվում է ISR-ից, եթե նրանից առբերման հարցում չի ստացվել replica.lag.time.max.ms միջակայքում:

Չկա պառակտված ուղեղի կամ հանգույցի կասեցում, ինչպես RabbitMQ-ում: Փոխարենը կրճատվում է ավելորդությունը։

Սցենար 2. Առաջնորդը չի տեսնում որևէ հետևորդ, բայց դեռ տեսնում է Zookeeper-ը

Բրինձ. 24. Սցենար 2. Առաջնորդ և երկու հետևորդ

Ցանցային կապի խզումը առաջատարին բաժանում է հետևորդներից, բայց բրոքերը դեռ կարող է տեսնել Zookeeper-ը: Ինչպես առաջին սցենարում, ISR-ը կրճատվում է, բայց այս անգամ միայն առաջատարին, քանի որ բոլոր հետևորդները դադարում են ուղարկել բեռնման հարցումներ: Նորից տրամաբանական բաժանում չկա։ Փոխարենը, նոր հաղորդագրությունների համար ավելորդության կորուստ կա մինչև կապի վերականգնումը: Zookeeper-ը շարունակում է պինգեր ստանալ և կարծում է, որ բրոքերը ողջ է և առողջ:

Բրինձ. 25. Սցենար 2. ISR-ը կրճատվել է միայն առաջատարին

Սցենար 3. Հետևորդը տեսնում է առաջնորդին, բայց չի տեսնում Կենդանաբանական այգու պահապանին

Հետևորդը բաժանվում է Zookeeper-ից, բայց ոչ առաջնորդի հետ բրոքերից։ Արդյունքում, հետևորդը շարունակում է ստանալ հարցումներ և լինել ISR-ի անդամ: Zookeeper-ն այլևս չի ստանում պինգեր և գրանցում է բրոքերային վթար, բայց քանի որ այն միայն հետևորդ է, ապա վերականգնվելուց հետո հետևանքներ չկան։

Բրինձ. 26. Սցենար 3. Հետևորդը շարունակում է բեռնման հարցումներ ուղարկել առաջնորդին

Սցենար 4. Առաջնորդը տեսնում է հետևորդներին, բայց չի տեսնում Zookeeper-ը

Բրինձ. 27. Սցենար 4. Առաջնորդ և երկու հետևորդ

Առաջնորդը բաժանված է Zookeeper-ից, բայց ոչ հետևորդներով բրոքերներից։

Բրինձ. 28. Սցենար 4. Առաջնորդը մեկուսացված է Zookeeper-ից

Որոշ ժամանակ անց Zookeeper-ը կարձանագրի բրոքերի ձախողումը և դրա մասին կտեղեկացնի վերահսկիչին: Նա իր հետեւորդների մեջ նոր առաջնորդ կընտրի։ Այնուամենայնիվ, սկզբնական ղեկավարը կշարունակի մտածել, որ ինքն է առաջատարը և կշարունակի ընդունել գրառումները ակս=1. Հետևորդներն այլևս նրան չեն ուղարկում առբերման հարցումներ, ուստի նա դրանք կհամարի մահացած և կփորձի փոքրացնել ISR-ն ինքն իրեն: Բայց քանի որ այն կապ չունի Zookeeper-ի հետ, այն չի կարողանա դա անել, և այդ պահին կհրաժարվի ընդունել հետագա գրառումները:

Сообщения ակս=բոլոր հաստատում չի ստանա, քանի որ ISR-ն նախ միացնում է բոլոր կրկնօրինակները, և հաղորդագրությունները չեն հասնում նրանց: Երբ սկզբնական ղեկավարը փորձի հեռացնել նրանց ISR-ից, նա չի կարողանա դա անել և ընդհանրապես կդադարի ընդունել որևէ հաղորդագրություն:

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

Բրինձ. 29. Սցենար 4. Բրոքեր 1-ի առաջատարը դառնում է հետևորդ ցանցի վերականգնումից հետո

Սցենար 5. Հետևորդը լիովին անջատված է ինչպես Կաֆկայի մյուս հանգույցներից, այնպես էլ Zookeeper-ից

Հետևորդը լիովին մեկուսացված է ինչպես Կաֆկայի մյուս հանգույցներից, այնպես էլ Zookeeper-ից: Նա պարզապես հեռացնում է իրեն ISR-ից մինչև ցանցը վերականգնվի, իսկ հետո հասնի մյուսներին:

Բրինձ. 30. Սցենար 5. Մեկուսացված հետևորդը հեռացվում է ISR-ից

Սցենար 6. Առաջնորդը լիովին անջատված է ինչպես Կաֆկայի մյուս հանգույցներից, այնպես էլ Zookeeper-ից

Բրինձ. 31. Սցենար 6. Առաջնորդ և երկու հետևորդ

Առաջնորդը լիովին մեկուսացված է իր հետևորդներից՝ վերահսկիչից և Կենդանաբանական այգու պահապանից։ Կարճ ժամանակահատվածում այն ​​կշարունակի ընդունել գրառումները ակս=1.

Բրինձ. 32. Սցենար 6. Առաջնորդի մեկուսացում Կաֆկայի և Կենդանաբանական այգու այլ հանգույցներից

Ժամկետը լրանալուց հետո հարցումներ չստացած replica.lag.time.max.ms, այն կփորձի փոքրացնել ISR-ը դեպի իրեն, բայց չի կարողանա դա անել, քանի որ Zookeeper-ի հետ կապ չկա, հետո կդադարի գրել գրություններ ընդունել։

Մինչդեռ Zookeeper-ը մեկուսացված միջնորդին մահացած կնշի, իսկ վերահսկիչը կընտրի նոր ղեկավար:

Բրինձ. 33. Սցենար 6. Երկու առաջնորդ

Բնօրինակ ղեկավարը կարող է ընդունել գրառումները մի քանի վայրկյան, բայց հետո դադարում է ընդունել ցանկացած հաղորդագրություն: Հաճախորդները թարմացվում են ամեն 60 վայրկյանը մեկ՝ վերջին մետատվյալներով: Նրանք կտեղեկացվեն առաջնորդի փոփոխության մասին և կսկսեն գրառումներ ուղարկել նոր ղեկավարին:

Բրինձ. 34. Սցենար 6. Արտադրողները անցնում են նոր ղեկավարի

Բոլոր հաստատված գրառումները, որոնք արվել են սկզբնական ղեկավարի կողմից, կապի կորստից հետո, կկորչեն: Երբ ցանցը վերականգնվի, սկզբնական ղեկավարը Zookeeper-ի միջոցով կբացահայտի, որ նա այլևս առաջատարը չէ: Այնուհետև այն կկտրի իր գրանցամատյանը նոր առաջնորդի HW-ին ընտրության պահին և կսկսի հարցումներ ուղարկել որպես հետևորդ:

Բրինձ. 35. Սցենար 6. Ցանցային կապի վերականգնումից հետո սկզբնական առաջնորդը դառնում է հետևորդ

Այս իրավիճակում տրամաբանական բաժանումը կարող է տեղի ունենալ կարճ ժամանակով, բայց միայն այն դեպքում, եթե ակս=1 и min.insync.replicas նաև 1. Տրամաբանական տարանջատումը ինքնաբերաբար ավարտվում է կամ ցանցի վերականգնումից հետո, երբ սկզբնական ղեկավարը հասկանում է, որ նա այլևս ղեկավարը չէ, կամ երբ բոլոր հաճախորդները հասկանում են, որ առաջնորդը փոխվել է և սկսում են գրել նոր ղեկավարին, որն առաջինը պատահի: Ամեն դեպքում, որոշ հաղորդագրություններ կկորչեն, բայց միայն հետ ակս=1.

Կա այս սցենարի մեկ այլ տարբերակ, որտեղ ցանցի բաժանվելուց անմիջապես առաջ հետևորդները հետ մնացին, իսկ առաջնորդը սեղմեց ISR-ը հենց իրեն: Այնուհետև այն դառնում է մեկուսացված կապի կորստի պատճառով: Ընտրվում է նոր ղեկավար, բայց սկզբնական ղեկավարը շարունակում է ընդունել գրառումները, նույնիսկ ակս=բոլոր, քանի որ ԻՍՌ-ում բացի նրանից ուրիշ մարդ չկա։ Այս գրառումները կկորչեն ցանցը վերականգնելուց հետո: Այս տարբերակից խուսափելու միակ միջոցը min.insync.replicas = 2.

Սցենար 7. Kafka Controller հանգույցը չի կարող տեսնել մեկ այլ Kafka հանգույց

Ընդհանուր առմամբ, երբ Կաֆկայի հանգույցի հետ կապը կորչի, վերահսկիչը չի կարողանա նրան փոխանցել առաջնորդի փոփոխության որևէ տեղեկություն: Վատագույն դեպքում դա կհանգեցնի կարճաժամկետ տրամաբանական տարանջատման, ինչպես 6-րդ սցենարում: Ավելի հաճախ, քան ոչ, բրոքերը պարզապես չի դառնա ղեկավարության թեկնածու, եթե վերջինս ձախողվի:

Սցենար 8. Kafka-ի վերահսկիչը չի տեսնում Zookeeper-ը

Zookeeper-ը չի ստանա պինգ ընկած վերահսկիչից և որպես վերահսկիչ կընտրի նոր Կաֆկա հանգույց: Բնօրինակ կարգավորիչը կարող է շարունակել ներկայանալ որպես այդպիսին, բայց Zookeeper-ից ծանուցումներ չի ստանում, ուստի որևէ առաջադրանք չի ունենա կատարելու: Ցանցը վերականգնելուց հետո նա կհասկանա, որ ինքն այլևս վերահսկիչ չէ, այլ դարձել է սովորական Կաֆկայի հանգույց։

Եզրակացություններ սցենարներից

Մենք տեսնում ենք, որ հետևորդների կապի կորուստը չի հանգեցնում հաղորդագրությունների կորստի, այլ պարզապես ժամանակավորապես նվազեցնում է ավելորդությունը, մինչև ցանցը վերականգնվի: Սա, իհարկե, կարող է հանգեցնել տվյալների կորստի, եթե մեկ կամ մի քանի հանգույցներ կորչեն:

Եթե ​​առաջնորդը բաժանվի Zookeeper-ից կապի կորստի պատճառով, դա կարող է հանգեցնել հաղորդագրությունների կորստի: ակս=1. Zookeeper-ի հետ շփման բացակայությունը հանգեցնում է երկու առաջնորդների հետ կարճ տրամաբանական պառակտման: Այս խնդիրը լուծվում է պարամետրով ակս=բոլոր.

Parameter min.insync.replicas երկու կամ ավելի կրկնօրինակների մեջ լրացուցիչ երաշխիք է տալիս, որ նման կարճաժամկետ սցենարները չեն հանգեցնի կորցրած հաղորդագրությունների, ինչպես Սցենար 6-ում:

Կորցրած հաղորդագրությունների ամփոփում

Եկեք թվարկենք Կաֆկայում տվյալների կորստի բոլոր եղանակները.

• Առաջնորդի ցանկացած ձախողում, եթե հաղորդագրությունները հաստատվել են օգտագործելով ակս=1
• Ղեկավարության ցանկացած անմաքուր անցում, այսինքն՝ ԻՍՌ-ից դուրս հետևորդին, նույնիսկ հետ ակս=բոլոր
• Առաջնորդին մեկուսացնել Zookeeper-ից, եթե հաղորդագրությունները հաստատվել են՝ օգտագործելով ակս=1
• Առաջնորդի լիակատար մեկուսացում, ով արդեն իսկ փոքրացրել է ISR խումբը դեպի իրեն: Բոլոր հաղորդագրությունները նույնիսկ կկորչեն ակս=բոլոր. Սա ճիշտ է միայն այն դեպքում, եթե min.insync.replicas=1.
• Բոլոր բաժանման հանգույցների միաժամանակյա ձախողումներ: Քանի որ հաղորդագրությունները ճանաչվում են հիշողությունից, որոշները դեռ չեն գրվել սկավառակի վրա: Սերվերները վերագործարկելուց հետո որոշ հաղորդագրություններ կարող են բացակայել:

Ղեկավարության անմաքուր անցումներից կարելի է խուսափել կամ արգելելով դրանք, կամ ապահովելով առնվազն երկու կրճատում: Առավել դիմացկուն կոնֆիգուրացիան համադրություն է ակս=բոլոր и min.insync.replicas 1-ից ավելին:

RabbitMQ-ի և Kafka-ի հուսալիության ուղղակի համեմատություն

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

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

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

• fsync ամեն մի քանի հարյուր միլիվայրկյան
• Հայելիի խափանումը կարելի է նկատել միայն այն բանից հետո, երբ փաթեթների գործողության ժամկետը լրանում է, որոնք ստուգում են յուրաքանչյուր հանգույցի առկայությունը (զուտ տիզ): Եթե ​​հայելին դանդաղում է կամ ընկնում, դա ավելացնում է ուշացումը:

Կաֆկայի խաղադրույքն այն է, որ եթե հաղորդագրությունը պահվում է մի քանի հանգույցներում, այն կարող է ընդունել հաղորդագրությունները հենց որ դրանք հարվածեն հիշողությանը: Դրա պատճառով ցանկացած տեսակի հաղորդագրություններ կորցնելու վտանգ կա (նույնիսկ ակս=բոլոր, min.insync.replicas=2) միաժամանակյա ձախողման դեպքում.

Ընդհանուր առմամբ, Kafka-ն ավելի լավ է ցուցադրում ծրագրային ապահովումը և նախատեսված է ի սկզբանե կլաստերների համար: Հուսալիության համար անհրաժեշտության դեպքում հետևորդների թիվը կարող է ավելացվել մինչև 11: Կրկնօրինակման գործակից 5 և կրկնօրինակների նվազագույն քանակը համաժամացման մեջ min.insync.replicas=3 հաղորդագրությունների կորուստը կդարձնի շատ հազվադեպ իրադարձություն: Եթե ​​ձեր ենթակառուցվածքը կարող է աջակցել կրկնօրինակման այս հարաբերակցությանը և ավելորդության մակարդակին, ապա կարող եք ընտրել այս տարբերակը:

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

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

Վերջապես, մի ​​մոռացեք մի շարք սխալների մասին RabbitMQ-ի և Kafka-ի կլաստերավորման և կրկնօրինակման մեխանիզմներում: Ժամանակի ընթացքում համակարգերը դարձել են ավելի հասուն և կայուն, բայց ոչ մի հաղորդագրություն երբեք 100%-ով ապահովագրված չի լինի կորստից: Բացի այդ, տվյալների կենտրոններում տեղի են ունենում լայնածավալ վթարներ:

Եթե ​​ես ինչ-որ բան բաց եմ թողել, սխալվել եմ, կամ դուք համաձայն չեք կետերից որևէ մեկի հետ, ազատ զգալ գրեք մեկնաբանություն կամ կապվեք ինձ հետ:

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

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

Ես տեսնում եմ այլ տեխնոլոգիաներ, որոնցում բացակայում է այս հուսալիությունը և երաշխավորված պատվիրումը, հետո նայում եմ RabbitMQ-ին և Kafka-ին և գիտակցում այս երկու համակարգերի անհավանական արժեքը:

Source: www.habr.com