Разбирање на брокери за пораки. Учење на механиката на пораки со ActiveMQ и Кафка. Поглавје 3. Кафка

Продолжение на преводот на мала книга:
Разбирање на брокери за пораки
автор: Јакуб Кораб, издавач: O'Reilly Media, Inc., датум на објавување: јуни 2017 година, ISBN: 9781492049296.

Претходен преведен дел: Разбирање на брокери за пораки. Учење на механиката на пораки со ActiveMQ и Кафка. Поглавје 1 Вовед

ПОГЛАВЈЕ 3

Кафка

Кафка беше развиен во LinkedIn за да се заобиколат некои од ограничувањата на традиционалните посредници за пораки и да се избегне потребата од поставување повеќе брокери за пораки за различни интеракции од точка до точка, што е опишано во оваа книга под „Зголемување и намалување“ на страница 28. Случаи на употреба LinkedIn во голема мера се потпира на еднонасочно внесување на многу големи количини на податоци, како што се кликови на страници и дневници за пристап, додека сè уште дозволува тие податоци да се користат од повеќе системи без да влијае на продуктивноста на производителите или другите потрошувачи. Всушност, причината за постоењето на Кафка е да го добие видот на архитектура за пораки што ја опишува Universal Data Pipeline.

Со оглед на оваа крајна цел, природно се појавија и други барања. Кафка треба:

• Бидете исклучително брзи
• Обезбедете поголем пропусен опсег кога работите со пораки
• Поддршка на моделите Publisher-Subscriber и Point-to-Point
• Не успорувајте со додавање потрошувачи. На пример, перформансите и на редот и на темата во ActiveMQ се деградираат како што расте бројот на потрошувачи на дестинацијата.
• Бидете хоризонтално скалабилни; ако еден брокер кој продолжува со пораки може да го стори тоа само со максимална брзина на дискот, тогаш има смисла да се оди подалеку од еден примерок на брокер за да се зголеми ефикасноста
• Ограничете го пристапот до складирање и повторно преземање пораки

За да го постигне сето ова, Кафка усвои архитектура која ги редефинира улогите и одговорностите на клиентите и брокерите за пораки. Моделот JMS е многу ориентиран кон брокерот, каде што брокерот е одговорен за дистрибуција на пораки и клиентите треба да се грижат само за испраќање и примање пораки. Кафка, од друга страна, е клиент-центричен, при што клиентот презема многу од карактеристиките на традиционалниот брокер, како што е правичната дистрибуција на релевантни пораки до потрошувачите, во замена за исклучително брз и скалабилен брокер. За луѓето кои работеле со традиционални системи за пораки, работата со Кафка бара фундаментална промена на мислењето.
Оваа инженерска насока доведе до создавање на инфраструктура за пораки способна да ја зголеми пропусната моќ за многу редови во споредба со конвенционалниот брокер. Како што ќе видиме, овој пристап доаѓа со компромиси, што значи дека Кафка не е погоден за одредени видови оптоварувања и инсталиран софтвер.

Модел на обединета дестинација

За да ги исполни барањата опишани погоре, Кафка комбинираше објавување-претплати и испраќање пораки од точка до точка под еден вид дестинација - тема. Ова е збунувачки за луѓето кои работеле со системи за пораки, каде што зборот „тема“ се однесува на механизам за емитување од кој (од темата) читањето е неиздржливо. Темите за Кафка треба да се сметаат за хибриден тип на дестинација, како што е дефинирано во воведот на оваа книга.

Во остатокот од ова поглавје, освен ако експлицитно не наведеме поинаку, терминот „тема“ ќе се однесува на тема на Кафка.

За целосно да разбереме како се однесуваат темите и какви гаранции даваат, прво треба да погледнеме како се имплементирани во Кафка.
Секоја тема во Кафка има свој дневник.
Производителите кои испраќаат пораки до Кафка пишуваат во овој дневник, а потрошувачите читаат од дневникот користејќи покажувачи кои постојано се движат напред. Периодично, Кафка ги брише најстарите делови од дневникот, без разлика дали пораките во тие делови се прочитани или не. Централен дел од дизајнот на Кафка е тоа што на брокерот не му е грижа дали пораките се читаат или не - тоа е одговорност на клиентот.

Термините „лог“ и „покажувач“ не се појавуваат во Кафка документација. Овие добро познати термини се користат овде за да помогнат во разбирањето.

Овој модел е сосема различен од ActiveMQ, каде пораките од сите редици се зачувани во истиот дневник, а брокерот ги означува пораките како избришани откако ќе бидат прочитани.
Ајде сега да копаме малку подлабоко и да го разгледаме дневникот на темата подетално.
Дневникот на Кафка се состои од неколку партиции (Слика 3-1). Кафка гарантира строг редослед во секоја партиција. Тоа значи дека пораките напишани на партицијата по одреден редослед ќе се читаат по истиот редослед. Секоја партиција се имплементира како тркалачка лог датотека која содржи подмножество (подмножество) на сите пораки испратени до темата од нејзините продуценти. Создадената тема стандардно содржи една партиција. Идејата за партиции е централна идеја на Кафка за хоризонтално скалирање.

Слика 3-1. Кафка партиции

Кога продуцентот испраќа порака до тема на Кафка, тој одлучува на која партиција да ја испрати пораката. Ова ќе го разгледаме подетално подоцна.

Читање пораки

Клиентот кој сака да ги чита пораките управува со именуван покажувач наречен група на потрошувачи, што укажува на офсет пораки во партицијата. Поместувањето е постепена позиција која започнува на 0 на почетокот на партицијата. Оваа група на потрошувачи, наведена во API преку user_defined 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. Двајца потрошувачи во иста група на потрошувачи читаат од различни партиции

Оваа шема во голема мера ја намалува сложеноста на брокерот Кафка во споредба со дистрибуцијата на пораките потребна за одржување на редот на JMS. Тука не треба да се грижите за следниве точки:

• Кој потрошувач треба да ја прими следната порака, врз основа на распределбата во круг, моменталниот капацитет на баферите за претходно преземање или претходните пораки (како за групите на пораки JMS).
• Кои пораки се испраќаат до кои потрошувачи и дали треба повторно да се доставуваат во случај на неуспех.

Сè што треба да направи брокерот Кафка е последователно да пренесува пораки до потрошувачот кога тој ќе ги побара.

Сепак, барањата за паралелизирање на лекторирањето и повторното испраќање на неуспешни пораки не исчезнуваат - одговорноста за нив едноставно преминува од брокерот на клиентот. Ова значи дека тие мора да се земат предвид во вашиот код.

Испраќање пораки

Одговорност на производителот на таа порака е да одлучи на која партиција да испрати порака. За да го разбереме механизмот со кој се прави ова, прво треба да размислиме што точно испраќаме.

Додека во JMS користиме структура на пораки со метаподатоци (заглавија и својства) и тело што го содржи товарот (payload), во Кафка пораката е пар „клуч-вредност“. Товарот на пораката се испраќа како вредност. Клучот, од друга страна, главно се користи за партиционирање и мора да содржи специфичен клуч за деловна логикада ставите поврзани пораки во истата партиција.

Во Поглавје 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.

Кафка вклучува контролни суми за откривање на корупција на пораките во продавницата и има целосен сет на безбедносни карактеристики. И покрај тоа, понекогаш се појавуваат барања специфични за индустријата, како што е горенаведеното.

Стратегијата за партиционирање на корисникот мора да гарантира дека сите поврзани пораки завршуваат во истата партиција. Иако ова изгледа едноставно, барањето може да биде комплицирано поради важноста на нарачувањето поврзани пораки и колку е фиксен бројот на партиции во една тема.

Бројот на партиции во темата може да се промени со текот на времето, бидејќи тие може да се додадат ако сообраќајот ги надминува првичните очекувања. Така, копчињата за пораки може да се поврзат со партицијата на која првично биле испратени, што подразбира дел од состојбата што треба да се сподели помеѓу примероците на производителите.

Друг фактор што треба да се земе предвид е рамномерната дистрибуција на пораките низ партициите. Вообичаено, клучевите не се распределуваат рамномерно низ пораките, а функциите за хаш не гарантираат правична дистрибуција на пораките за мал сет на клучеви.
Важно е да се напомене дека како и да одберете да ги поделите пораките, можеби ќе треба повторно да се употреби самиот сепаратор.

Размислете за барањето да се реплицираат податоците помеѓу кластерите на Кафка на различни географски локации. За таа цел, Кафка доаѓа со алатка за командна линија наречена MirrorMaker, која се користи за читање пораки од еден кластер и нивно пренесување во друг.

MirrorMaker мора да ги разбере клучевите на реплицираната тема за да одржува релативен редослед помеѓу пораките при реплицирање помеѓу кластери, бидејќи бројот на партиции за таа тема може да не е ист во два кластери.

Прилагодените стратегии за партиционирање се релативно ретки, бидејќи стандардното хаширање или круг-робин функционира добро во повеќето сценарија. Меѓутоа, ако ви требаат силни гаранции за нарачка или треба да извлечете метаподатоци од носивоста, тогаш партиционирањето е нешто што треба внимателно да го разгледате.

Приспособливоста и придобивките од перформансите на Кафка доаѓаат од префрлањето на некои од одговорностите на традиционалниот брокер на клиентот. Во овој случај, се донесува одлука да се дистрибуираат потенцијално поврзани пораки меѓу неколку потрошувачи кои работат паралелно.

Брокерите на JMS, исто така, треба да се справат со такви барања. Интересно е тоа што механизмот за испраќање поврзани пораки до истиот потрошувач, имплементиран преку JMS Message Groups (варијација на стратегијата за лепливо балансирање на оптоварување (SLB)), исто така бара од испраќачот да ги означи пораките како поврзани. Во случајот на JMS, брокерот е одговорен за испраќање на оваа група поврзани пораки до еден потрошувач од многуте, и пренесување на сопственоста на групата доколку потрошувачот падне.

Договори за производители

Поделбата не е единственото нешто што треба да се земе предвид при испраќање пораки. Ајде да ги погледнеме методите send() на класата Producer во Java API:

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

Веднаш треба да се забележи дека двата методи враќаат Future, што покажува дека операцијата за испраќање не се извршува веднаш. Резултатот е дека пораката (ProducerRecord) е напишана во баферот за испраќање за секоја активна партиција и испратена до брокерот како нишка во заднина во библиотеката на клиентите на Кафка. Иако ова ги прави работите неверојатно брзи, тоа значи дека неискусна апликација може да изгуби пораки ако нејзиниот процес е запрен.

Како и секогаш, постои начин да се направи операцијата за испраќање посигурна на сметка на перформансите. Големината на овој тампон може да се постави на 0, а низата на апликацијата што испраќа ќе биде принудена да почека додека не заврши преносот на пораката до брокерот, како што следува:

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

Повеќе за читање пораки

Читањето пораки има дополнителни сложености за кои треба да се шпекулира. За разлика од JMS API, кој може да активира слушател на пораки како одговор на порака, на Потрошувачите Кафка само анкети. Ајде внимателно да го разгледаме методот анкета ()се користи за оваа намена:

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

Повратната вредност на методот е контејнерска структура која содржи повеќе објекти евиденција на потрошувачите од потенцијално неколку партиции. евиденција на потрошувачите сам по себе е објект на држач за пар клуч-вредност со поврзани метаподатоци, како што е партицијата од која е изведен.

Како што беше дискутирано во Поглавје 2, мора да имаме на ум што се случува со пораките откако ќе бидат успешно или неуспешни обработени, на пример, ако клиентот не може да ја обработи пораката или ако таа прекине. Во JMS, ова беше управувано преку режим на потврда. Брокерот или ќе ја избрише успешно обработената порака или повторно ќе ја достави необработената или лажната порака (под претпоставка дека се користени трансакции).
Кафка работи многу поинаку. Пораките не се бришат во брокерот по лекторирањето, а што се случува при неуспех е одговорност на самиот код за лекторирање.

Како што рековме, групата на потрошувачи е поврзана со поместувањето во дневникот. Позицијата на дневникот поврзана со ова поместување одговара на следната порака што треба да се издаде како одговор на анкета (). Временската точка кога оваа поместување се зголемува е одлучувачка за читање.

Враќајќи се на моделот за читање што беше дискутиран претходно, обработката на пораките се состои од три фази:

1. Добијте порака за читање.
2. Обработете ја пораката.
3. Потврдете ја пораката.

Потрошувачот на Кафка доаѓа со опција за конфигурација enable.auto.commit. Ова е често користена стандардна поставка, како што е вообичаено со поставките што го содржат зборот „автоматски“.

Пред Кафка 0.10, клиентот што ја користи оваа опција ќе испрати поместување на последната прочитана порака на следниот повик анкета () по обработката. Ова значеше дека сите пораки што веќе биле преземени може да се обработат повторно ако клиентот веќе ги обработил, но неочекувано биле уништени пред да се јави анкета (). Бидејќи брокерот не одржува никаква состојба за тоа колку пати е прочитана пораката, следниот потрошувач што ќе ја врати таа порака нема да знае дека се случило ништо лошо. Ова однесување беше псевдо-трансакциско. Поместувањето беше извршено само ако пораката беше успешно обработена, но ако клиентот прекине, брокерот повторно ќе ја испрати истата порака до друг клиент. Ова однесување беше во согласност со гаранцијата за испорака на пораката "барем еднаш".

Во Кафка 0.10, кодот на клиентот е променет така што извршувањето периодично се активира од библиотеката на клиентот, како што е конфигурирано auto.commit.interval.ms. Ова однесување е некаде помеѓу режимите JMS AUTO_ACKNOWLEDGE и DUPS_OK_ACKNOWLEDGE. Кога се користи автоматско извршување, пораките може да се извршат без оглед на тоа дали навистина се обработени - ова може да се случи во случај на бавен потрошувач. Ако потрошувачот прекине, пораките ќе бидат преземени од следниот потрошувач, почнувајќи од посветената позиција, што може да резултира со пропуштена порака. Во овој случај, Кафка не ги изгубил пораките, кодот за читање едноставно не ги обработил.

Овој режим го има истото ветување како во верзијата 0.9: пораките може да се обработуваат, но ако не успее, поместувањето може да не се изврши, што потенцијално ќе предизвика испораката да се удвои. Колку повеќе пораки добивате при извршувањето анкета (), толку повеќе овој проблем.

Како што беше дискутирано во „Читање пораки од редица“ на страница 21, не постои такво нешто како еднократна испорака на порака во системот за пораки кога се земаат предвид режимите на неуспех.

Во Кафка, постојат два начина да се изврши (да се изврши) офсет (офсет): автоматски и рачно. Во двата случаи, пораките може да се обработуваат повеќе пати ако пораката била обработена, но не успеала пред извршувањето. Можете исто така да изберете да не ја обработувате пораката воопшто ако извршувањето се случило во заднина и вашиот код бил завршен пред да може да се обработи (можеби во Кафка 0.9 и порано).

Можете да го контролирате процесот на рачно поместување на извршување во API-то на потрошувачите на Кафка со поставување на параметарот enable.auto.commit за лажно и експлицитно повикување на еден од следниве методи:

void commitSync();
void commitAsync();

Ако сакате да ја обработите пораката „барем еднаш“, мора рачно да го извршите поместувањето со commitSync()со извршување на оваа команда веднаш по обработката на пораките.

Овие методи не дозволуваат да се потврдат пораките пред да се обработат, но тие не прават ништо за да ги елиминираат потенцијалните доцнења во обработката додека даваат изглед дека се трансакциски. Во Кафка нема трансакции. Клиентот нема можност да го направи следново:

• Автоматски врати лажна порака. Самите потрошувачи мора да се справат со исклучоците што произлегуваат од проблематични носивост и прекини на задниот дел, бидејќи не можат да се потпрат на брокерот за повторно доставување пораки.
• Испраќајте пораки до повеќе теми во една атомска операција. Како што ќе видиме наскоро, контролата врз различни теми и партиции може да биде на различни машини во кластерот Кафка кои не ги координираат трансакциите кога се испраќаат. Во моментот на пишување, беше направена одредена работа за да се овозможи ова со KIP-98.
• Поврзете читање на една порака од една тема со испраќање друга порака на друга тема. Повторно, архитектурата на Кафка зависи од многу независни машини кои работат како еден автобус и не се прави обид тоа да се сокрие. На пример, нема API компоненти што би ви овозможиле да се поврзете потрошувачот и Продуцент во трансакција. Во JMS, ова е обезбедено од објектот сесијаод кои се создаваат Продуценти на пораки и ПоракаПотрошувачи.

Ако не можеме да се потпреме на трансакции, како можеме да обезбедиме семантика поблиска до оние што ги обезбедуваат традиционалните системи за пораки?

Ако постои можност дека поместувањето на потрошувачот може да се зголеми пред да се обработи пораката, како на пример за време на пад на потрошувачот, тогаш потрошувачот нема начин да знае дали неговата група на потрошувачи ја пропуштила пораката кога и е доделена партиција. Значи, една стратегија е да се премота офсет на претходната позиција. API-то за потрошувачи на Кафка ги обезбедува следниве методи за ова:

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

Метод барај () може да се користи со метод
offsetsForTimes (Карта временски печатиЗа пребарување) да се премота назад во состојба во одреден момент во минатото.

Имплицитно, користењето на овој пристап значи дека е многу веројатно некои пораки кои претходно биле обработени повторно да бидат прочитани и обработени. За да го избегнеме ова, можеме да користиме идемпотентно читање, како што е опишано во Поглавје 4, за да ги следиме претходно прегледаните пораки и да ги елиминираме дупликатите.

Алтернативно, вашиот потрошувачки код може да биде едноставен, сè додека е прифатливо губењето или дуплирањето на пораката. Кога ги разгледуваме случаите на употреба за кои најчесто се користи Кафка, како што се справување со настани од дневници, метрика, следење кликнувања итн., разбираме дека губењето на поединечни пораки веројатно нема да има значително влијание врз околните апликации. Во такви случаи, стандардните вредности се сосема прифатливи. Од друга страна, ако вашата апликација треба да испраќа плаќања, мора внимателно да се грижите за секоја поединечна порака. Сè се сведува на контекст.

Личните набљудувања покажуваат дека како што се зголемува интензитетот на пораките, вредноста на секоја поединечна порака се намалува. Големите пораки имаат тенденција да бидат вредни кога се гледаат во збирна форма.

Висока достапност

Пристапот на Кафка кон високата достапност е многу различен од пристапот на ActiveMQ. Кафка е дизајниран околу кластери кои се намалуваат каде што сите брокерски примероци примаат и дистрибуираат пораки во исто време.

Кластерот Кафка се состои од повеќе примероци на брокер што работат на различни сервери. Кафка беше дизајниран да работи на обичен самостоен хардвер, каде што секој јазол има свое посебно складирање. Употребата на мрежно прикачено складирање (SAN) не се препорачува бидејќи повеќе компјутерски јазли можат да се натпреваруваат за време.Ыe интервали на складирање и создаваат конфликти.

Кафка е секогаш на систем. Многу големи корисници на Кафка никогаш не ги затвораат своите кластери и софтверот секогаш се ажурира со последователно рестартирање. Ова се постигнува со гарантирање на компатибилност со претходната верзија за пораки и интеракции помеѓу брокерите.

Брокери поврзани со кластер на сервери Зоочувар, кој делува како регистар на податоци за конфигурација и се користи за координирање на улогите на секој брокер. Самиот ZooKeeper е дистрибуиран систем кој обезбедува висока достапност преку репликација на информации преку воспоставување кворум.

Во основниот случај, се креира тема во кластерот Кафка со следните својства:

• Бројот на партиции. Како што беше дискутирано претходно, точната вредност што се користи овде зависи од посакуваното ниво на паралелно читање.
• Факторот на репликација (фактор) одредува колку примероци на брокер во кластерот треба да содржат логови за оваа партиција.

Користејќи го ZooKeepers за координација, Кафка се обидува правично да дистрибуира нови партиции меѓу брокерите во кластерот. Ова е направено од еден примерок кој делува како контролор.

За време на траење за секоја партиција на тема Контролор додели улоги на брокер лидер (водач, мајстор, презентер) и следбеници (следбеници, робови, подредени). Брокерот, кој делува како лидер за оваа партиција, е одговорен за примање на сите пораки испратени до него од производителите и дистрибуција на пораките до потрошувачите. Кога пораките се испраќаат до партиција за тема, тие се реплицираат на сите брокерски јазли кои дејствуваат како следбеници за таа партиција. Се повикува секој јазол што содржи логови за партиција реплика. Брокерот може да дејствува како лидер за некои партиции и како следбеник за други.

Се повикува следбеник кој ги содржи сите пораки што ги држи лидерот синхронизирана реплика (реплика која е во синхронизирана состојба, во синхронизирана реплика). Ако брокерот што дејствува како лидер за партиција се намали, секој брокер што е ажуриран или синхронизиран за таа партиција може да ја преземе лидерската улога. Тоа е неверојатно одржлив дизајн.

Дел од конфигурацијата на производителот е параметарот курови, што одредува колку реплики мора да го потврдат (потврдат) примањето на пораката пред нишката за апликација да продолжи да испраќа: 0, 1 или сите. Ако е поставено на сите, тогаш кога ќе се прими порака, лидерот ќе испрати потврда назад до продуцентот штом ќе добие потврди (потврда) за записот од неколку знаци (вклучувајќи го и самиот) дефинирани со поставувањето на темата min.insync.реплики (стандардно 1). Ако пораката не може успешно да се реплицира, тогаш производителот ќе фрли исклучок од апликација (NotEnoughReplicas или Забелешка ДоволноРепликаПослеДа приложи).

Типична конфигурација создава тема со фактор на репликација од 3 (1 лидер, 2 следбеници по партиција) и параметарот min.insync.реплики е поставено на 2. Во овој случај, кластерот ќе дозволи еден од брокерите што управуваат со партицијата за тема да се спушти без да влијае на апликациите на клиентите.

Ова нè враќа на веќе познатата размена помеѓу перформансите и доверливоста. Репликацијата се случува на сметка на дополнителното време на чекање за потврди (потврда) од следбениците. Иако, бидејќи работи паралелно, репликацијата на најмалку три јазли ги има истите перформанси како два (игнорирајќи го зголемувањето на искористеноста на пропусниот опсег на мрежата).

Со користење на оваа шема за репликација, Кафка умно ја избегнува потребата физички да ја запише секоја порака на диск со операцијата синхронизација (). Секоја порака испратена од продуцентот ќе биде запишана во дневникот на партицијата, но како што беше дискутирано во Поглавје 2, пишувањето во датотека првично се прави во баферот на оперативниот систем. Ако оваа порака се реплицира на друг пример на Кафка и е во неговото сеќавање, загубата на лидерот не значи дека самата порака е изгубена - може да биде преземена од синхронизирана реплика.
Одбивање да се изврши операцијата синхронизација () значи дека Кафка може да прима пораки толку брзо колку што може да ги запише на меморија. Спротивно на тоа, колку подолго можете да избегнете испирање на меморијата на дискот, толку подобро. Поради оваа причина, не е невообичаено на брокерите на Кафка да им се доделуваат 64 GB или повеќе меморија. Оваа употреба на меморија значи дека еден пример на Кафка лесно може да работи со брзина многу илјадници пати поголема од традиционалниот брокер за пораки.

Кафка исто така може да се конфигурира да ја применува операцијата синхронизација () за пораки пакети. Бидејќи сè во Кафка е ориентирано кон пакети, тој всушност работи доста добро за многу случаи на употреба и е корисна алатка за корисници кои бараат многу силни гаранции. Голем дел од чистите перформанси на Кафка доаѓаат од пораките што се испраќаат до брокерот како пакети и дека овие пораки се читаат од брокерот во последователни блокови користејќи нулта копија операции (операции при кои не се извршува задачата за копирање податоци од една мемориска област во друга). Последново е голема добивка во перформансите и ресурсите и е возможна само преку употреба на основна структура на податоци од дневникот што ја дефинира шемата за партиции.

Можни се многу подобри перформанси во кластерот Кафка отколку со еден брокер на Кафка, бидејќи партициите на теми може да се размерат на многу одделни машини.

Резултатите од

Во ова поглавје, погледнавме како архитектурата на Кафка го резамислува односот помеѓу клиентите и брокерите за да обезбеди неверојатно стабилна линија за пораки, со пропусност многу пати поголема од онаа на конвенционалниот брокер за пораки. Разговаравме за функционалноста што ја користи за да го постигне ова и накратко ја разгледавме архитектурата на апликациите што ја обезбедуваат оваа функционалност. Во следното поглавје, ќе ги разгледаме вообичаените проблеми што апликациите базирани на пораки треба да ги решат и да разговараат за стратегиите за справување со нив. Ќе го завршиме поглавјето со тоа што ќе објасниме како воопшто да зборуваме за технологиите за пораки за да можете да ја оцените нивната соодветност за вашите случаи на употреба.

Претходен преведен дел: Разбирање на брокери за пораки. Учење на механиката на пораки со ActiveMQ и Кафка. Поглавје 1

Преводот е направен: tele.gg/middle_java

Да се ​​продолжи ...

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.

Дали Кафка се користи во вашата организација?

• Да

• Не

• Претходно користено, сега не

• Планираме да користиме

Гласаа 38 корисници. 8 корисници беа воздржани.

Извор: www.habr.com