В последна статија го разгледавме кластерирањето на 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.ш за рачно прераспределување.

Ориз. 6. Реплики по ребалансирање

Ова беше поедноставена верзија на неуспехот, но реалноста е посложена, иако тука нема ништо премногу комплицирано. Сè се сведува на синхронизирани реплики (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.

Акс=1 и ISR

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

Во овој пример, производителот ја има вредноста acks=1. Делот е дистрибуиран низ сите три брокери. Брокер 3 заостанува, се синхронизираше со лидерот пред осум секунди и сега заостанува 7456 пораки. Брокерот 1 заостануваше само една секунда. Нашиот продуцент праќа порака и брзо добива повратен одговор, без преоптоварување на бавни или мртви следбеници што лидерот не ги чека.

Ориз. 7. ISR со три реплики

Брокерот 2 не успее и продуцентот добива грешка при поврзувањето. Откако раководството ќе помине на брокерот 1, губиме 123 пораки. Следбеникот на брокерот 1 беше дел од ISR, но не беше целосно синхронизиран со лидерот кога падна.

Ориз. 8. Пораките се губат кога ќе падне

Во конфигурација bootstrap.сервери Производителот има наведени неколку брокери и може да праша друг брокер кој е новиот лидер на секцијата. Потоа воспоставува врска со брокерот 1 и продолжува да испраќа пораки.

Ориз. 9. Испраќањето пораки продолжува по кратка пауза

Брокерот 3 е уште позади. Испраќа барања за преземање, но не може да се синхронизира. Ова може да се должи на бавното мрежно поврзување помеѓу брокери, проблем со складирањето итн. Тој е отстранет од ISR. Сега ISR се состои од една реплика - лидер! Производителот продолжува да испраќа пораки и да прима потврди.

Ориз. 10. Следбеникот на брокерот 3 е отстранет од ISR

Брокерот 1 се намалува, а лидерската улога оди на брокерот 3 со губење на 15286 пораки! Производителот добива порака за грешка при поврзувањето. Транзицијата кон лидер надвор од ISR беше можна само поради поставувањето нечист.лидер.избор.овозможи=точно. Доколку е инсталиран во лажни, тогаш транзицијата нема да се случи и сите барања за читање и пишување ќе бидат одбиени. Во овој случај, чекаме брокерот 1 да се врати со неговите недопрени податоци во репликата, кој повторно ќе го преземе раководството.

Ориз. 11. Брокерот 1 паѓа. Кога ќе се случи дефект, голем број пораки се губат

Продуцентот воспоставува врска со последниот брокер и гледа дека тој сега е водач на секцијата. Почнува да испраќа пораки до брокерот 3.

Ориз. 12. По кратка пауза, пораките повторно се испраќаат до делот 0

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

Акс=сите и 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 умира и лидерската транзиција со нечиста поставка резултира со голема загуба на податоци

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

Но, што ако сакаме да ја зголемиме безбедноста на податоците? Можете да ставите нечист.лидер.избор.овозможи = лажен, но тоа нема нужно да не заштити од губење на податоци. Ако лидерот падна тешко и ги зеде податоците со себе, тогаш пораките сè уште се губат, плус достапноста се губи додека администраторот не ја врати ситуацијата.

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

Acks=all, min.insync.replicas и ISR

Со конфигурација на тема min.insync.реплики Го зголемуваме нивото на безбедност на податоците. Ајде повторно да го поминеме последниот дел од претходното сценарио, но овој пат со min.insync.replicas=2.

Значи, брокерот 2 има лидер на реплика и следбеникот на брокерот 3 е отстранет од ISR.

Ориз. 19. ISR од две реплики

Брокерот 2 паѓа и лидерството преминува на брокерот 1 без губење на пораки. Но, сега ISR се состои од само една реплика. Ова не го исполнува минималниот број за примање записи, и затоа брокерот одговара на обидот за запишување со грешка NotEnoughReplicas.

Ориз. 20. Бројот на ISR е за еден помал од наведеното во min.insync.replicas

Оваа конфигурација ја жртвува достапноста за конзистентност. Пред да ја потврдиме пораката, осигуруваме дека е напишана на најмалку две реплики. Ова му дава на производителот многу поголема самодоверба. Овде, губењето на пораката е можно само ако две реплики не успеат истовремено во краток интервал додека пораката не се реплицира на дополнителен следбеник, што е малку веројатно. Но, ако сте супер параноични, можете да го поставите факторот на репликација на 5, и min.insync.реплики од 3. Овде тројца брокери мора да паднат во исто време за да го изгубат рекордот! Се разбира, вие плаќате за оваа сигурност во дополнителна латентност.

Кога пристапноста е неопходна за безбедност на податоците

Како во случај со RabbitMQ, понекогаш пристапноста е неопходна за безбедност на податоците. Еве за што треба да размислите:

• Дали може издавачот едноставно да врати грешка и да побара од услугата или корисникот да се обиде повторно подоцна?
• Може ли издавачот да ја зачува пораката локално или во базата на податоци за да се обиде повторно подоцна?

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

Значењето на ISR

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

Сами го избираме значењето replica.lag.time.max.ms според вашите потреби. Во суштина, овој параметар значи колку доцнење сме подготвени да прифатиме кога акс=сите. Стандардната вредност е десет секунди. Ако ова е премногу долго за вас, можете да го намалите. Тогаш фреквенцијата на промени во ISR ќе се зголеми, бидејќи следбениците ќе се отстрануваат и почесто се додаваат.

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

Гаранција за поврзување со клиентот

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

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

Архитектура на консензус на Кафка

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

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

Zookeeper ја складира состојбата на кластерот:

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

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

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

За секој контролер на секција:

• ажурира информации во Zookeeper за ISR и лидер;
• Испраќа команда LeaderAndISR до секој брокер што е домаќин на реплика на оваа партиција, информирајќи ги брокерите за ISR и лидерот.

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

Секој лидер е одговорен за регрутирање на ISR. Поставки replica.lag.time.max.ms одредува кој ќе влезе таму. Кога ISR се менува, лидерот пренесува нови информации до Zookeeper.

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

Ориз. 21. Консензус на Кафка

Протокол за репликација

Разбирањето на деталите за репликацијата ви помага подобро да ги разберете потенцијалните сценарија за губење податоци.

Барања за земање примероци, поместување на крајот на евиденцијата (LEO) и ознака за висока вода (HW)

Сметавме дека следбениците периодично испраќаат барања за преземање до лидерот. Стандардниот интервал е 500 ms. Ова се разликува од RabbitMQ по тоа што во RabbitMQ репликацијата не е иницирана од огледалото на редот, туку од главниот. Мајсторот турка промени на огледалата.

Лидерот и сите следбеници ја зачувуваат ознаката Log End Offset (LEO) и Highwater (HW). Ознаката LEO го зачувува поместувањето на последната порака во локалната реплика, а HW го задржува поместувањето на последното обврзување. Запомнете дека за статусот на обврзување, пораката мора да се одржува во сите ISR реплики. Ова значи дека ЛЕО обично е малку пред HW.

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

Забележете дека „перзистентно“ значи запишано во меморијата, а не на дискот. За изведба, Кафка се синхронизира со диск во одреден интервал. RabbitMQ исто така има таков интервал, но ќе испрати потврда до издавачот само откако господарот и сите огледала ќе ја напишат пораката на дискот. Програмерите на Кафка, од причини за изведба, решија да испратат ак веднаш штом пораката ќе биде запишана во меморијата. Кафка се обложува дека вишокот го неутрализира ризикот од накратко складирање на признаените пораки само во меморијата.

Неуспех на лидерот

Кога лидерот паѓа, Zookeeper го известува контролорот и тој избира нова реплика на лидер. Новиот лидер поставува нова ознака HW според неговиот ЛАВ. Следбениците потоа добиваат информации за новиот лидер. Во зависност од верзијата на Кафка, следбеникот ќе избере едно од двете сценарија:

1. Ќе го скрати локалниот дневник на познат HW и ќе испрати барање до новиот лидер за пораки по оваа ознака.
2. Ќе испрати барање до лидерот да го дознае ХВ во моментот кога бил избран за лидер, а потоа да го скрати дневникот до ова поместување. Потоа ќе започне да прави периодични барања за преземање почнувајќи од ова поместување.

Следбеникот можеби ќе треба да го скрати дневникот од следниве причини:

• Кога лидерот не успее, првиот следбеник во комплетот ISR регистриран во Zookeeper победува на изборите и станува лидер. Сите следбеници на ISR, иако се сметаат за „синхронизирани“, можеби не добиле копии од сите пораки од поранешниот лидер. Сосема е можно истакнатиот следбеник да ја нема најсовремената копија. Кафка гарантира дека нема дивергенција меѓу репликите. Така, за да се избегнат несогласувања, секој следбеник мора да го скрати својот дневник на вредноста HW на новиот лидер во моментот на неговиот избор. Ова е уште една причина зошто поставувањето акс=сите толку важно за конзистентноста.
• Пораките периодично се запишуваат на дискот. Ако сите јазли на кластерот не успеат во исто време, тогаш репликите со различни поместувања ќе бидат зачувани на дисковите. Можно е кога брокерите ќе се вратат на интернет, новиот лидер што ќе биде избран да биде зад неговите следбеници бидејќи бил зачуван на дискот пред другите.

Повторно обединување со кластерот

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

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

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

Губење на поврзување

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

Подолу се дадени неколку сценарија за неуспех на поврзувањето:

• Сценарио 1: Следбеникот не го гледа лидерот, но сепак го гледа Зоочуварот.
• Сценарио 2: Лидерот не гледа следбеници, но сепак го гледа Zookeeper.
• Сценарио 3: Следбеникот го гледа лидерот, но не го гледа Зоочуварот.
• Сценарио 4: Лидерот ги гледа следбениците, но не го гледа Зоочуварот.
• Сценарио 5: Следбеникот е целосно одделен и од другите јазли на Кафка и од Zookeeper.
• Сценарио 6: Водачот е целосно одделен од другите јазли на Кафка и од Zookeeper.
• Сценарио 7: Јазолот на контролорот Кафка не може да види друг Кафка-јазол.
• Сценарио 8: Контролорот на Кафка не го гледа Zookeeper.

Секое сценарио има свое однесување.

Сценарио 1: Следбеникот не го гледа лидерот, но сепак го гледа Zookeeeper

Ориз. 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. Лидерот ги гледа следбениците, но не го гледа Зоочуварот

Ориз. 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.реплики исто така 1. Логичкото раздвојување автоматски завршува или откако ќе се врати мрежата, кога оригиналниот лидер ќе сфати дека тој повеќе не е лидер, или кога сите клиенти ќе сфатат дека лидерот се променил и ќе почнат да му пишуваат на новиот лидер - што и да се случи прво. Во секој случај, некои пораки ќе се изгубат, но само со акс=1.

Постои уште една варијанта на ова сценарио каде што, непосредно пред поделбата на мрежата, следбениците заостанаа и лидерот го компресираше ISR само за себе. Потоа станува изолиран поради губење на поврзувањето. Се избира нов лидер, но првичниот лидер продолжува да прифаќа записи, дури и акс=сите, бидејќи освен него нема никој друг во ИСР. Овие записи ќе бидат изгубени откако ќе се врати мрежата. Единствениот начин да се избегне оваа опција е min.insync.replicas = 2.

Сценарио 7: Јазолот на контролорот на Кафка не може да види друг јазол на Кафка

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

Сценарио 8: Контролорот на Кафка не го гледа Zookeeper

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

Заклучоци од сценаријата

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

Ако лидерот се одвои од Zookeeper поради губење на поврзувањето, тоа може да резултира со губење на пораките од акс=1. Недостатокот на комуникација со Zookeeper предизвикува кратка логична поделба со двајцата водачи. Овој проблем се решава со параметарот акс=сите.

Параметар min.insync.реплики во две или повеќе реплики обезбедува дополнително уверување дека таквите краткорочни сценарија нема да резултираат со изгубени пораки како во Сценариото 6.

Резиме на изгубени пораки

Ајде да ги наведеме сите начини на кои можете да изгубите податоци во Кафка:

• Секое неуспех на лидерот ако пораките биле потврдени со користење акс=1
• Секоја нечиста транзиција на лидерство, односно на следбеник надвор од ИСР, дури и со акс=сите
• Изолирање на водачот од Zookeeper доколку пораките се потврдени со користење акс=1
• Целосна изолација на лидерот кој веќе ја намали групата ИСР во себе. Сите пораки ќе бидат изгубени, дури и акс=сите. Ова е точно само ако min.insync.replicas=1.
• Симултани неуспеси на сите јазли на партицијата. Бидејќи пораките се потврдуваат од меморијата, некои можеби сè уште не се напишани на дискот. По рестартирање на серверите, некои пораки може да недостасуваат.

Нечистите лидерски транзиции може да се избегнат или со нивна забрана или со обезбедување на најмалку два отпуштања. Најиздржливата конфигурација е комбинација акс=сите и min.insync.реплики повеќе од 1.

Директна споредба на веродостојноста на RabbitMQ и Кафка

За да се обезбеди сигурност и висока достапност, двете платформи имплементираат примарен и секундарен систем за репликација. Сепак, RabbitMQ има Ахилова пета. При повторно поврзување по дефект, јазлите ги отфрлаат своите податоци и синхронизацијата е блокирана. Овој двоен удар ја доведува во прашање долговечноста на големите редици во RabbitMQ. Ќе мора да прифатите или намален технолошки вишок или долго време на блокирање. Намалувањето на вишокот го зголемува ризикот од масовна загуба на податоци. Но, ако редиците се мали, тогаш заради вишок, може да се решат кратки периоди на недостапност (неколку секунди) со користење на повторени обиди за поврзување.

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

RabbitMQ е супериорен во однос на Кафка во доверливоста кога повеќе сервери во кластер не успеваат во исто време. Како што веќе рековме, RabbitMQ испраќа потврда до издавачот само откако пораката е напишана на дискот од страна на главниот и сите ретровизори. Но, ова додава дополнителна латентност од две причини:

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

Облогот на Кафка е дека ако пораката е зачувана низ повеќе јазли, таа може да ги потврди пораките веднаш штом ќе стигнат до меморијата. Поради ова, постои ризик од губење на пораки од кој било тип (дури и акс=сите, min.insync.replicas=2) во случај на истовремен дефект.

Генерално, Кафка покажува подобри перформанси на софтверот и е дизајниран од основа за кластери. Бројот на следбеници може да се зголеми на 11 доколку е потребно за доверливост. Фактор на репликација 5 и минимален број на реплики во синхронизација min.insync.replicas=3 ќе го направи губењето на пораката многу редок настан. Ако вашата инфраструктура може да го поддржи овој сооднос на репликација и ниво на вишок, тогаш можете да ја изберете оваа опција.

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

Еден противотров за ранливоста на RabbitMQ на големи редици е да ги раздели на многу помали редици. Ако не барате целосно нарачување на целата редица, туку само релевантни пораки (на пример, пораки од одреден клиент), или воопшто не нарачувате ништо, тогаш оваа опција е прифатлива: погледнете го мојот проект Ребалансер да се подели редот (проектот е сè уште во рана фаза).

Конечно, не заборавајте за голем број грешки во механизмите за групирање и репликација и на RabbitMQ и на Кафка. Со текот на времето, системите станаа позрели и постабилни, но ниедна порака никогаш нема да биде 100% безбедна од загуба! Покрај тоа, несреќи од големи размери се случуваат во центрите за податоци!

Ако нешто пропуштив, згрешив или не се согласувате со некоја од точките, слободно пишете коментар или контактирајте ме.

Често ме прашуваат: „Што да одберам, Кафка или RabbitMQ?“, „Која платформа е подобра?“. Вистината е дека навистина зависи од вашата ситуација, моментално искуство итн. Се двоумам да дадам мое мислење бидејќи би било преголемо поедноставување да се препорача една платформа за сите случаи на употреба и можни ограничувања. Ја напишав оваа серија написи за да можете да формирате свое мислење.

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

Гледам други технологии на кои им недостасува оваа доверливост и гарантирано нарачка, потоа ги гледам RabbitMQ и Kafka и ја сфаќам неверојатната вредност на двата од овие системи.

Извор: www.habr.com