Հասկանալով հաղորդագրության բրոքերներին: Սովորում ենք հաղորդագրությունների փոխանակման մեխանիզմը ActiveMQ-ի և Kafka-ի հետ: Գլուխ 3. Կաֆկա

Փոքր գրքի թարգմանության շարունակությունը.
Հասկանալով հաղորդագրությունների բրոքերներին
հեղինակ՝ Յակուբ Քորաբ, հրատարակիչ՝ O'Reilly Media, Inc., Հրատարակման ամսաթիվ՝ հունիս 2017, ISBN՝ 9781492049296։

Նախորդ թարգմանված մասը. Հասկանալով հաղորդագրության բրոքերներին: Սովորում ենք հաղորդագրությունների փոխանակման մեխանիզմը ActiveMQ-ի և Kafka-ի հետ: Գլուխ 1 Ներածություն

ԳԼՈՒԽ 3

Kafka

Kafka-ն մշակվել է LinkedIn-ի կողմից՝ շրջանցելու ավանդական հաղորդագրությունների բրոքերների որոշ սահմանափակումներ և խուսափելու համար ստեղծելու բազմաթիվ հաղորդագրությունների բրոքերներ տարբեր կետ առ կետ փոխազդեցությունների համար, որոնք նկարագրված են այս գրքում՝ «Մեծացնել և դուրս գալ» էջ 28-ում: Օգտագործման դեպքեր LinkedIn-ը հիմնականում հենվել է շատ մեծ քանակությամբ տվյալների միակողմանի կլանման վրա, ինչպիսիք են էջերի սեղմումները և մուտքի գրանցամատյանները, միևնույն ժամանակ թույլ է տալիս այդ տվյալները օգտագործել բազմաթիվ համակարգերի կողմից՝ չազդելով արտադրողների կամ այլ սպառողների արտադրողականության վրա: Իրականում, Կաֆկայի գոյության պատճառն այն է, որ ստանա հաղորդագրությունների այնպիսի ճարտարապետություն, որը նկարագրում է Համընդհանուր տվյալների խողովակաշարը:

Հաշվի առնելով այս վերջնական նպատակը, բնականաբար, առաջացան այլ պահանջներ: Կաֆկան պետք է.

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

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

Միասնական նպատակակետ մոդել

Վերը նկարագրված պահանջները կատարելու համար Կաֆկան համատեղել է հրապարակել-բաժանորդագրվել և կետ առ կետ հաղորդագրությունների փոխանակումը մեկ տեսակի նպատակակետի ներքո. թեմա. Սա շփոթեցնող է մարդկանց համար, ովքեր աշխատել են հաղորդագրությունների փոխանցման համակարգերի հետ, որտեղ «թեմա» բառը վերաբերում է հեռարձակման մեխանիզմին, որից (թեմայից) ընթերցումը անտանելի է: Կաֆկայի թեմաները պետք է դիտվեն որպես հիբրիդային նպատակակետ, ինչպես սահմանված է այս գրքի ներածությունում:

Այս գլխի մնացած մասի համար, եթե մենք հստակորեն այլ բան չենք ասում, «թեմա» տերմինը վերաբերելու է Կաֆկայի թեմային:

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

«Մատյան» և «ցուցիչ» տերմինները չեն հայտնվում Կաֆկայի փաստաթղթեր. Այս հայտնի տերմիններն այստեղ օգտագործվում են հասկանալու համար:

Այս մոդելը լիովին տարբերվում է ActiveMQ-ից, որտեղ բոլոր հերթերի հաղորդագրությունները պահվում են նույն մատյանում, և բրոքերը նշում է հաղորդագրությունները որպես ջնջված՝ դրանք կարդալուց հետո:
Եկեք հիմա մի փոքր ավելի խորանանք և ավելի մանրամասն նայենք թեմայի մատյանին:
Կաֆկայի տեղեկամատյանը բաղկացած է մի քանի միջնորմներից (Նկար 3 1 -) Կաֆկան երաշխավորում է խիստ պատվեր յուրաքանչյուր միջնորմում: Սա նշանակում է, որ բաժանման վրա որոշակի հերթականությամբ գրված հաղորդագրությունները կկարդան նույն հերթականությամբ: Յուրաքանչյուր բաժանում իրականացվում է որպես շարժակազմի մատյան ֆայլ, որը պարունակում է ենթաբազմություն իր արտադրողների կողմից թեմային ուղարկված բոլոր հաղորդագրությունների (ենթաբազմություն): Ստեղծված թեման պարունակում է լռելյայն մեկ բաժին: Միջնորմների գաղափարը Կաֆկայի կենտրոնական գաղափարն է հորիզոնական մասշտաբի համար:

Նկար 3-1. Միջնապատեր Կաֆկա

Երբ պրոդյուսերը հաղորդագրություն է ուղարկում Կաֆկայի թեմային, նա որոշում է, թե որ բաժնին ուղարկի հաղորդագրությունը: Այս մասին ավելի մանրամասն կանդրադառնանք ավելի ուշ:

Հաղորդագրությունների ընթերցում

Հաճախորդը, որը ցանկանում է կարդալ հաղորդագրությունները, ղեկավարում է անվանված ցուցիչը սպառողների խումբ, որը մատնանշում է օֆսեթ հաղորդագրությունները բաժանման մեջ: Օֆսեթը աստիճանական դիրք է, որը սկսվում է 0-ից բաժանման սկզբում: Այս սպառողների խումբը, որը հղում է արվում API-ում օգտվողի կողմից սահմանված group_id-ի միջոցով, համապատասխանում է մեկ տրամաբանական սպառող կամ համակարգ.

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

Ընթերցանության խնդիրը կարելի է ներկայացնել հետևյալ կերպ.

• Թեման ունի բազմաթիվ միջնորմներ
• Սպառողների մի քանի խմբեր կարող են միաժամանակ օգտագործել թեմա
• Սպառողների մի խումբ կարող է ունենալ մի քանի առանձին դեպքեր

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

Սպառողներ և սպառողների խմբեր

Եկեք որպես ելակետ վերցնենք թեմա մեկ բաժանմամբ (Նկար 3 2 -).

Նկար 3-2. Սպառողը կարդում է միջնորմից

Երբ սպառողի օրինակը միանում է իր սեփական group_id-ով այս թեմային, նրան վերագրվում է կարդալու բաժին և օֆսեթ այդ բաժնում: Այս օֆսեթի դիրքը հաճախորդում կազմաձևված է որպես ամենավերջին դիրքի (նորագույն հաղորդագրություն) կամ ամենավաղ դիրքի (ամենահին հաղորդագրություն) ցուցիչ: Սպառողը խնդրում է (հարցումներ) հաղորդագրություններ թեմայից, ինչը հանգեցնում է դրանց հաջորդական ընթերցման մատյանից:
Օֆսեթ դիրքը պարբերաբար վերադարձվում է Կաֆկային և պահվում որպես հաղորդագրություններ ներքին թեմայում _սպառողական_օֆսեթներ. Կարդացված հաղորդագրությունները դեռևս չեն ջնջվում, ի տարբերություն սովորական բրոքերի, և հաճախորդը կարող է հետ վերադարձնել օֆսեթը՝ արդեն դիտված հաղորդագրությունները վերամշակելու համար:

Երբ երկրորդ տրամաբանական սպառողը միանում է՝ օգտագործելով այլ group_id, այն կառավարում է երկրորդ ցուցիչը, որը անկախ է առաջինից (Նկար 3 3 -). Այսպիսով, Կաֆկայի թեման գործում է որպես հերթ, որտեղ կա մեկ սպառող, և ինչպես սովորական հրապարակում-բաժանորդագրվել (pub-sub) թեմա, որին բաժանորդագրվում են բազմաթիվ սպառողներ, հավելյալ առավելություններով, որ բոլոր հաղորդագրությունները պահվում են և կարող են մշակվել մի քանի անգամ:

Նկար 3-3. Տարբեր սպառողների խմբերի երկու սպառողներ կարդում են նույն բաժանմունքից

Սպառողներ սպառողների խմբի մեջ

Երբ սպառողների մեկ օրինակը կարդում է տվյալ բաժանմունքից, այն լիովին վերահսկում է ցուցիչը և մշակում է հաղորդագրությունները, ինչպես նկարագրված է նախորդ բաժնում:
Եթե ​​սպառողների մի քանի օրինակներ միացված են միևնույն group_id-ով մի միջնորմով թեմայի հետ, ապա վերջին միացած օրինակին կտրվի վերահսկողություն ցուցիչի վրա և այդ պահից սկսած այն կստանա բոլոր հաղորդագրությունները (Նկար 3 4 -).

Նկար 3-4. Նույն սպառողների խմբի երկու սպառողներ կարդում են նույն բաժանմունքից

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

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

Ամենից հաճախ, երբ մենք ստեղծում ենք սպառողների մի քանի օրինակներ, մենք դա անում ենք կա՛մ հաղորդագրությունները զուգահեռ մշակելու, կա՛մ ընթերցման արագությունը բարձրացնելու, կա՛մ ընթերցման գործընթացի կայունությունը բարձրացնելու համար: Քանի որ սպառողի միայն մեկ օրինակ կարող է միաժամանակ կարդալ տվյալ բաժանմունքից, ինչպե՞ս է դա ձեռք բերվում Կաֆկայում:

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

Կաֆկայում այս խնդրի լուծման կանոնական ճանապարհը բОավելի շատ միջնորմներ:

Բաժանում

Բաժանմունքները ընթերցանության և թեմայի մասշտաբավորման հիմնական մեխանիզմն են մեկ բրոքերային օրինակի թողունակությունից դուրս: Սա ավելի լավ հասկանալու համար եկեք դիտարկենք մի իրավիճակ, երբ կա երկու միջնապատերով թեմա և մեկ սպառող բաժանորդագրված է այս թեմային (Նկար 3 5 -).

Նկար 3-5. Մեկ սպառողը կարդում է մի քանի միջնորմներից

Այս սցենարում սպառողին տրվում է հսկողություն իր group_id-ին համապատասխանող ցուցիչների վրա երկու բաժիններում և սկսում է հաղորդագրություններ կարդալ երկու բաժանմունքներից:
Երբ այս թեմային ավելացվում է լրացուցիչ սպառող նույն group_id-ի համար, Կաֆկան բաժանումներից մեկը վերաբաշխում է առաջինից երկրորդ սպառողին: Դրանից հետո սպառողի յուրաքանչյուր օրինակ կկարդա թեմայի մեկ բաժին (Նկար 3 6 -).

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

Նկար 3-6. Նույն սպառողների խմբի երկու սպառողներ կարդում են տարբեր բաժիններից

Այս սխեման զգալիորեն նվազեցնում է Kafka բրոքերի բարդությունը՝ համեմատած JMS հերթը պահպանելու համար անհրաժեշտ հաղորդագրությունների բաշխման հետ: Այստեղ ձեզ հարկավոր չէ անհանգստանալ հետևյալ կետերի համար.

• Ո՞ր սպառողը պետք է ստանա հաջորդ հաղորդագրությունը` հիմնվելով շրջանաձև տեղաբաշխման, նախնական առբերման բուֆերների ներկայիս հզորության կամ նախորդ հաղորդագրությունների վրա (ինչպես JMS հաղորդագրությունների խմբերի համար):
• Ո՞ր հաղորդագրություններն են ուղարկվում սպառողներին և արդյոք դրանք պետք է նորից առաքվեն ձախողման դեպքում:

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

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

Հաղորդագրություններ ուղարկելը

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

Մինչ JMS-ում մենք օգտագործում ենք մետատվյալներով (վերնագրեր և հատկություններ) հաղորդագրության կառուցվածք և օգտակար բեռ պարունակող մարմին (բեռնատար), Կաֆկայում հաղորդագրությունը հետևյալն է. զույգ «բանալի-արժեք». Հաղորդագրության ծանրաբեռնվածությունը ուղարկվում է որպես արժեք: Բանալին, մյուս կողմից, հիմնականում օգտագործվում է բաժանման համար և պետք է պարունակի բիզնես տրամաբանության հատուկ բանալինհարակից հաղորդագրությունները նույն բաժանման մեջ դնելու համար:

Գլուխ 2-ում մենք քննարկեցինք առցանց խաղադրույքների սցենարը, որտեղ առնչվող իրադարձությունները պետք է մշակվեն մեկ սպառողի կողմից.

1. Օգտագործողի հաշիվը կազմաձևված է:
2. Գումարը մուտքագրվում է հաշվին:
3. Կատարվում է խաղադրույք, որը հաշվից գումար է հանում:

Եթե ​​յուրաքանչյուր իրադարձություն թեմայում տեղադրված հաղորդագրություն է, ապա բնական բանալին կլինի հաշվի ID-ն:
Երբ հաղորդագրությունն ուղարկվում է Kafka Producer API-ի միջոցով, այն փոխանցվում է բաժանման ֆունկցիայի, որը, հաշվի առնելով հաղորդագրությունը և Կաֆկա կլաստերի ներկայիս վիճակը, վերադարձնում է բաժանման ID-ն, որին պետք է ուղարկվի հաղորդագրությունը: Այս ֆունկցիան իրականացվում է Java-ում Partitioner ինտերֆեյսի միջոցով:

Այս ինտերֆեյսը ունի հետևյալ տեսքը.

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

Գրելով ձեր սեփական բաժանման ռազմավարությունը

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

Քանի որ ստորագրության արժեքը կախված կլինի ծանրաբեռնվածությունից, Partitioner ինտերֆեյսի կանխադրված հեշավորման ռազմավարությունը հուսալիորեն չի խմբավորի առնչվող հաղորդագրությունները: Հետևաբար, մենք պետք է գրենք մեր սեփական ռազմավարությունը, որը կվերլուծի այս բանալին և կբաժանի accountId արժեքը:

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

Օգտագործողի բաժանման ռազմավարությունը պետք է ապահովի, որ բոլոր առնչվող հաղորդագրությունները հայտնվում են նույն բաժանման մեջ: Թեև սա պարզ է թվում, պահանջը կարող է բարդանալ առնչվող հաղորդագրություններ պատվիրելու կարևորությամբ և թեմայի մեջ բաժանումների քանակի ֆիքսվածությամբ:

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

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

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

MirrorMaker-ը պետք է հասկանա կրկնվող թեմայի բանալիները՝ կլաստերների միջև կրկնօրինակելիս հաղորդագրությունների միջև հարաբերական կարգը պահպանելու համար, քանի որ այդ թեմայի բաժանումների թիվը կարող է նույնը չլինել երկու կլաստերներում:

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

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

JMS բրոքերները նույնպես պետք է զբաղվեն նման պահանջներով: Հետաքրքիր է, որ նույն սպառողին առնչվող հաղորդագրություններ ուղարկելու մեխանիզմը, որն իրականացվում է JMS Message Groups-ի միջոցով (կպչուն բեռի հավասարակշռման (SLB) ռազմավարության փոփոխություն), նույնպես պահանջում է ուղարկողից նշել հաղորդագրությունները որպես առնչվող: JMS-ի դեպքում բրոքերը պատասխանատու է այս խմբի հետ կապված հաղորդագրությունների ուղարկման համար շատ սպառողներից մեկին և փոխանցելու խմբի սեփականությունը, եթե սպառողը ընկնի:

Արտադրողների պայմանագրեր

Բաժանումը միակ բանը չէ, որ պետք է հաշվի առնել հաղորդագրություններ ուղարկելիս: Եկեք նայենք Java API-ում Producer դասի send() մեթոդներին.

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

Ավելին հաղորդագրություններ կարդալու մասին

Հաղորդագրությունների ընթերցումն ունի լրացուցիչ բարդություններ, որոնց մասին պետք է ենթադրել: Ի տարբերություն JMS API-ի, որը կարող է գործարկել հաղորդագրություն ունկնդիր՝ ի պատասխան հաղորդագրության, Սպառող Կաֆկան միայն հարցումներ. Եկեք ավելի սերտ նայենք մեթոդին հարցում ()օգտագործվում է այս նպատակով.

ConsumerRecords < K, V > poll(long timeout);

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

Ինչպես քննարկվել է 2-րդ գլխում, մենք պետք է հիշենք, թե ինչ է տեղի ունենում հաղորդագրությունների հետ, երբ դրանք հաջող կամ անհաջող մշակվել են, օրինակ, եթե հաճախորդը չի կարողանում մշակել հաղորդագրությունը կամ եթե այն ընդհատվում է: JMS-ում դա կարգավորվում էր ճանաչման ռեժիմի միջոցով: Բրոքերը կա՛մ կջնջի հաջողությամբ մշակված հաղորդագրությունը, կա՛մ նորից կառաքի չմշակված կամ կեղծ հաղորդագրությունը (ենթադրելով, որ գործարքներ են օգտագործվել):
Կաֆկան շատ այլ կերպ է աշխատում. Հաղորդագրությունները բրոքերում չեն ջնջվում սրբագրումից հետո, և այն, ինչ տեղի է ունենում ձախողման դեպքում, հենց սրբագրման ծածկագրի պատասխանատվությունն է:

Ինչպես ասացինք, սպառողների խումբը կապված է գրանցամատյանում օֆսեթի հետ: Այս օֆսեթի հետ կապված գրանցամատյանի դիրքը համապատասխանում է հաջորդ հաղորդագրությանը, որը պետք է տրվի ի պատասխան հարցում (). Ժամանակի այն կետը, երբ այս փոխհատուցումը մեծանում է, որոշիչ է կարդալու համար:

Վերադառնալով ավելի վաղ քննարկված ընթերցման մոդելին՝ հաղորդագրությունների մշակումը բաղկացած է երեք փուլից.

1. Առբերեք հաղորդագրություն կարդալու համար:
2. Մշակել հաղորդագրությունը:
3. Հաստատեք հաղորդագրությունը:

Kafka-ի սպառողը գալիս է կազմաձևման տարբերակով enable.auto.commit. Սա հաճախ օգտագործվող լռելյայն կարգավորում է, ինչպես սովորական է «ավտո» բառը պարունակող կարգավորումների դեպքում:

Նախքան Kafka 0.10-ը, այս տարբերակն օգտագործող հաճախորդը կուղարկի հաջորդ զանգի ժամանակ կարդացված վերջին հաղորդագրության օֆսեթը: հարցում () վերամշակումից հետո։ Սա նշանակում էր, որ ցանկացած հաղորդագրություն, որն արդեն առբերվել է, կարող է վերամշակվել, եթե հաճախորդն արդեն մշակել է դրանք, բայց անսպասելիորեն ոչնչացվել է նախքան զանգահարելը: հարցում (). Քանի որ բրոքերը չի նշում, թե քանի անգամ է կարդացվել հաղորդագրությունը, հաջորդ սպառողը, ով առբերում է այդ հաղորդագրությունը, չի իմանա, որ ոչ մի վատ բան տեղի է ունեցել: Այս պահվածքը կեղծ գործարքային էր: Օֆսեթը կատարվել է միայն այն դեպքում, եթե հաղորդագրությունը հաջողությամբ մշակվել է, բայց եթե հաճախորդը ընդհատվի, բրոքերը նորից նույն հաղորդագրությունը կուղարկի մեկ այլ հաճախորդի: Այս պահվածքը համապատասխանում էր հաղորդագրությունների առաքման երաշխիքին»գոնե մեկ անգամ»:

Kafka 0.10-ում հաճախորդի կոդը փոխվել է այնպես, որ commit-ը պարբերաբար գործարկվի հաճախորդի գրադարանի կողմից, ինչպես կազմաձևված է: auto.commit.interval.ms. Այս պահվածքը գտնվում է JMS AUTO_ACKNOWLEDGE և DUPS_OK_ACKNOWLEDGE ռեժիմների միջև: Autocommit-ից օգտվելիս հաղորդագրությունները կարող են կատարվել՝ անկախ նրանից, թե դրանք իրականում մշակվել են, դա կարող է տեղի ունենալ դանդաղ սպառողի դեպքում: Եթե ​​սպառողը ընդհատի, հաղորդագրությունները կբերվեն հաջորդ սպառողի կողմից՝ սկսած ստանձնած դիրքից, ինչը կարող է հանգեցնել բաց թողնված հաղորդագրության: Այս դեպքում Կաֆկան չի կորցրել հաղորդագրությունները, ընթերցման կոդը պարզապես չի մշակել դրանք։

Այս ռեժիմն ունի նույն խոստումը, ինչ 0.9 տարբերակում. հաղորդագրությունները կարող են մշակվել, բայց եթե այն ձախողվի, օֆսեթը կարող է չկատարվել, ինչը կարող է հանգեցնել առաքման կրկնապատկման: Որքան շատ հաղորդագրություններ եք վերցնում կատարման ժամանակ հարցում (), այնքան այս խնդիրը:

Ինչպես քննարկվել է «Հերթից հաղորդագրություններ կարդալը» էջ 21-ում, հաղորդագրության համակարգում հաղորդագրությունների միանգամյա առաքում չկա, երբ հաշվի են առնվում ձախողման ռեժիմները:

Կաֆկայում կա օֆսեթ (օֆսեթ) կատարելու (կատարելու) երկու եղանակ՝ ավտոմատ և ձեռքով: Երկու դեպքում էլ հաղորդագրությունները կարող են մշակվել մի քանի անգամ, եթե հաղորդագրությունը մշակվել է, բայց ձախողվել է մինչև հանձնումը: Կարող եք նաև ընտրել չմշակել հաղորդագրությունն ընդհանրապես, եթե հանձնումը տեղի է ունեցել հետին պլանում, և ձեր կոդը ավարտվել է նախքան այն մշակելը (հնարավոր է, Kafka 0.9 և ավելի վաղ):

Դուք կարող եք կառավարել ձեռքով օֆսեթ հանձնելու գործընթացը Kafka-ի սպառողական API-ում՝ սահմանելով պարամետրը enable.auto.commit կեղծ և բացահայտորեն կանչել հետևյալ մեթոդներից մեկը.

void commitSync();
void commitAsync();

Եթե ​​ցանկանում եք մշակել «առնվազն մեկ անգամ» հաղորդագրությունը, դուք պետք է ձեռքով կատարեք օֆսեթը commitSync ()այս հրամանը կատարելով հաղորդագրությունները մշակելուց անմիջապես հետո:

Այս մեթոդները թույլ չեն տալիս հաղորդագրությունները հաստատել նախքան դրանք մշակելը, բայց դրանք ոչինչ չեն անում վերամշակման հնարավոր հետաձգումները վերացնելու համար՝ միաժամանակ տալով գործարքային տեսք: Կաֆկայում գործարքներ չկան. Հաճախորդը հնարավորություն չունի անելու հետևյալը.

• Կեղծված հաղորդագրությունը ավտոմատ կերպով հետ վերադարձնել: Սպառողներն իրենք պետք է զբաղվեն բացառություններով, որոնք առաջանում են խնդրահարույց ծանրաբեռնվածությունից և հետին պլանի անջատումներից, քանի որ նրանք չեն կարող ապավինել բրոքերին՝ հաղորդագրությունները նորից առաքելու համար:
• Ուղարկեք հաղորդագրություններ բազմաթիվ թեմաների մեկ ատոմային գործողության մեջ: Ինչպես շուտով կտեսնենք, տարբեր թեմաների և բաժանմունքների նկատմամբ վերահսկողությունը կարող է լինել Կաֆկա կլաստերի տարբեր մեքենաների վրա, որոնք չեն համակարգում գործարքները, երբ ուղարկվում են: Այս գրելու պահին որոշակի աշխատանք է կատարվել KIP-98-ով դա հնարավոր դարձնելու համար:
• Մի թեմայից մեկ հաղորդագրություն կարդալը կապեք մեկ այլ թեմայի մեկ այլ հաղորդագրություն ուղարկելու հետ: Կրկին, Կաֆկայի ճարտարապետությունը կախված է բազմաթիվ անկախ մեքենաներից, որոնք աշխատում են որպես մեկ ավտոբուս, և ոչ մի փորձ չի արվում դա թաքցնել: Օրինակ, չկան API բաղադրիչներ, որոնք թույլ կտան ձեզ կապել սպառող и Պրոդյուսեր գործարքի մեջ: JMS-ում սա տրամադրվում է օբյեկտի կողմից նիստորոնցից ստեղծվում են MessageProducers и ՀաղորդագրությունՍպառողների.

Եթե ​​մենք չենք կարող ապավինել գործարքներին, ինչպե՞ս կարող ենք իմաստաբանություն տրամադրել ավանդական հաղորդագրությունների համակարգերի տրամադրածներին ավելի մոտ:

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

մեթոդ փնտրել () կարող է օգտագործվել մեթոդով
offsetsForTimes (Քարտեզ timestampsToSearch) հետ շրջվել դեպի ինչ-որ մի վիճակ անցյալի ինչ-որ կոնկրետ կետում:

Անուղղակիորեն, այս մոտեցման օգտագործումը նշանակում է, որ շատ հավանական է, որ որոշ հաղորդագրություններ, որոնք նախկինում մշակվել են, նորից կարդան և վերամշակվեն: Դրանից խուսափելու համար մենք կարող ենք օգտագործել անիմաստ ընթերցանություն, ինչպես նկարագրված է 4-րդ գլխում, նախկինում դիտված հաղորդագրություններին հետևելու և կրկնօրինակները վերացնելու համար:

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

Անձնական դիտարկումները ցույց են տալիս, որ հաղորդագրությունների ինտենսիվության աճին զուգահեռ յուրաքանչյուր առանձին հաղորդագրության արժեքը նվազում է: Խոշոր հաղորդագրությունները հակված են արժեքավոր լինել, երբ դիտվում են ագրեգացված տեսքով:

Բարձր մատչելիություն

Կաֆկայի մոտեցումը բարձր հասանելիության նկատմամբ շատ տարբերվում է ActiveMQ-ի մոտեցումից: Kafka-ն նախագծված է մասշտաբային կլաստերների շուրջ, որտեղ բրոքերների բոլոր օրինակները միաժամանակ ստանում և տարածում են հաղորդագրություններ:

Կաֆկա կլաստերը բաղկացած է բազմաթիվ բրոքերային օրինակներից, որոնք աշխատում են տարբեր սերվերների վրա: Kafka-ն նախատեսված էր սովորական ինքնուրույն սարքաշարի վրա աշխատելու համար, որտեղ յուրաքանչյուր հանգույց ունի իր հատուկ պահեստը: Ցանցային կցված պահեստի (SAN) օգտագործումը խորհուրդ չի տրվում, քանի որ մի քանի հաշվողական հանգույցներ կարող են մրցակցել ժամանակի համար:ЫՊահպանման ընդմիջումներն ու կոնֆլիկտների ստեղծումը:

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

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

Հիմնական դեպքում Կաֆկա կլաստերում ստեղծվում է թեմա հետևյալ հատկություններով.

• Բաժինների քանակը. Ինչպես արդեն քննարկվել է, այստեղ օգտագործվող ճշգրիտ արժեքը կախված է զուգահեռ ընթերցման ցանկալի մակարդակից:
• Կրկնօրինակման գործոնը (գործոնը) որոշում է, թե կլաստերի քանի բրոքերային օրինակ պետք է պարունակի այս բաժանման տեղեկամատյանները:

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

Գործարկման ժամանակ յուրաքանչյուր թեմայի բաժանման համար Վերահսկիչ դերեր հատկացնել բրոքերին առաջնորդ (առաջնորդ, վարպետ, հաղորդավար) և հետևորդներ (հետևորդներ, ստրուկներ, ենթականեր): Բրոքերը, հանդես գալով որպես այս բաժանման առաջատար, պատասխանատու է արտադրողների կողմից իրեն ուղարկված բոլոր հաղորդագրությունները ստանալու և հաղորդագրությունները սպառողներին բաշխելու համար: Երբ հաղորդագրություններն ուղարկվում են թեմայի բաժանման, դրանք կրկնօրինակվում են բոլոր բրոքերային հանգույցներին, որոնք գործում են որպես այդ բաժանման հետևորդներ: Յուրաքանչյուր հանգույց, որը պարունակում է բաժանման տեղեկամատյաններ, կոչվում է կրկնօրինակը. Բրոքերը կարող է որոշ բաժանումների համար առաջնորդ լինել, իսկ մյուսների համար՝ որպես հետևորդ:

Հետևորդը, որը պարունակում է առաջնորդի բոլոր հաղորդագրությունները, կոչվում է համաժամեցված կրկնօրինակ (կրկնօրինակ, որը համաժամանակյա վիճակում է, in-sync կրկնօրինակ): Եթե ​​բաժանման համար որպես առաջնորդ հանդես եկող բրոքեր դադարում է, ցանկացած բրոքեր, որը արդիական է կամ համաժամանակացված է այդ բաժանման համար, կարող է ստանձնել առաջնորդի դերը: Դա աներեւակայելի կայուն դիզայն է:

Արտադրողի կոնֆիգուրացիայի մի մասը պարամետրն է ակսեր, որը որոշում է, թե քանի կրկնօրինակներ պետք է հաստատեն (հաստատեն) հաղորդագրության ստացումը, նախքան հայտի շարանը շարունակի ուղարկելը՝ 0, 1 կամ բոլորը: Եթե ​​սահմանված է բոլորը, այնուհետև, երբ հաղորդագրություն ստացվի, առաջնորդը հաստատում կուղարկի արտադրողին հենց որ նա ստանա ձայնագրության հաստատումներ (հաստատումներ) թեմայի կարգավորումով սահմանված մի քանի ազդանշաններից (ներառյալ ինքն իրեն): min.insync.replicas (կանխադրված 1): Եթե ​​հաղորդագրությունը հնարավոր չէ հաջողությամբ կրկնօրինակել, ապա արտադրողը բացառություն կներկայացնի հավելվածի (NotEnoughReplicas կամ NotEnoughReplicasAfterAppend).

Տիպիկ կոնֆիգուրացիան ստեղծում է թեմա 3-ի կրկնօրինակման գործակցով (1 առաջնորդ, 2 հետևորդ յուրաքանչյուր բաժանման համար) և պարամետրով min.insync.replicas սահմանվում է 2: Այս դեպքում կլաստերը թույլ կտա թեմայի բաժանումը կառավարող բրոքերներից մեկին իջնել՝ առանց հաճախորդի հավելվածների վրա ազդելու:

Սա մեզ հետ է բերում կատարողականի և հուսալիության արդեն ծանոթ փոխզիջմանը: Կրկնօրինակումը տեղի է ունենում հետևորդների կողմից հաստատումների (հաստատումների) լրացուցիչ սպասման ժամանակի հաշվին: Չնայած, քանի որ այն աշխատում է զուգահեռաբար, կրկնօրինակումը առնվազն երեք հանգույցների վրա ունի նույն արդյունավետությունը, ինչ երկուսը (անտեսելով ցանցի թողունակության օգտագործման աճը):

Օգտագործելով այս կրկնօրինակման սխեման՝ Կաֆկան խելամտորեն խուսափում է գործողության ընթացքում յուրաքանչյուր հաղորդագրություն սկավառակի վրա ֆիզիկապես գրելու անհրաժեշտությունից: համաժամեցում (). Արտադրողի կողմից ուղարկված յուրաքանչյուր հաղորդագրություն գրվելու է բաժանման մատյանում, սակայն ինչպես քննարկվել է Գլուխ 2-ում, ֆայլին գրելն ի սկզբանե կատարվում է օպերացիոն համակարգի բուֆերում: Եթե ​​այս հաղորդագրությունը կրկնօրինակվում է Կաֆկայի մեկ այլ օրինակի վրա և գտնվում է նրա հիշողության մեջ, առաջնորդի կորուստը չի նշանակում, որ հաղորդագրությունն ինքնին կորել է. այն կարող է տիրանալ համաժամացված կրկնօրինակով:
Վիրահատությունից հրաժարվելը համաժամեցում () նշանակում է, որ Կաֆկան կարող է հաղորդագրություններ ստանալ այնքան արագ, որքան կարող է դրանք գրել հիշողության մեջ: Ընդհակառակը, որքան երկար կարողանաք խուսափել հիշողությունը սկավառակի վրա լցվելուց, այնքան լավ: Այս պատճառով հազվադեպ չէ, որ Kafka բրոքերներին հատկացվում է 64 ԳԲ կամ ավելի հիշողություն: Հիշողության այս օգտագործումը նշանակում է, որ Կաֆկայի մեկ օրինակը հեշտությամբ կարող է աշխատել հազարավոր անգամ ավելի արագ, քան ավանդական հաղորդագրության միջնորդը:

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

Շատ ավելի լավ կատարողականություն հնարավոր է Kafka կլաստերում, քան մեկ Kafka բրոքերով, քանի որ թեմաների բաժանումները կարող են մասշտաբավորվել բազմաթիվ առանձին մեքենաներում:

Արդյունքները

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

Նախորդ թարգմանված մասը. Հասկանալով հաղորդագրության բրոքերներին: Սովորում ենք հաղորդագրությունների փոխանակման մեխանիզմը ActiveMQ-ի և Kafka-ի հետ: Գլուխ 1

Թարգմանությունը կատարված է. tele.gg/middle_java

Շարունակելի…

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Կաֆկան օգտագործվո՞ւմ է ձեր կազմակերպությունում:

• Այո

• Ոչ

• Նախկինում օգտագործված է, այժմ՝ ոչ

• Մենք նախատեսում ենք օգտագործել

Քվեարկել է 38 օգտատեր։ 8 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com