В соңғы мақала ақауларға төзімділік пен жоғары қолжетімділік үшін RabbitMQ кластерін қарастырдық. Енді Апачи Кафкаға тереңірек үңілейік.

Мұнда репликация бірлігі бөлім болып табылады. Әрбір тақырып бір немесе бірнеше бөлімнен тұрады. Әр бөлімде ізбасарлары бар немесе жоқ көшбасшы бар. Тақырыпты құру кезінде сіз бөлімдер санын және репликация коэффициентін көрсетесіз. Әдеттегі мән - 3, бұл үш репликаны білдіреді: бір жетекші және екі ізбасар.

Күріш. 1. Төрт бөлім үш брокерлерге бөлінеді

Барлық оқу және жазу сұраулары көшбасшыға жіберіледі. Жазушылар соңғы хабарламаларды алу үшін көшбасшыға мерзімді түрде сұраулар жібереді. Тұтынушылар ешқашан ізбасарларға жүгінбейді; соңғысы тек артықшылық пен ақауларға төзімділік үшін бар.

Бөлім ақаулығы

Брокер сәтсіздікке ұшыраған кезде, бірнеше бөлімдердің басшылары жиі сәтсіздікке ұшырайды. Олардың әрқайсысында басқа түйіннен келген ізбасар көшбасшы болады. Шындығында, бұл әрдайым бола бермейді, өйткені синхрондау факторы да әсер етеді: синхрондалған ізбасарлар бар ма, ал егер жоқ болса, синхрондалмаған көшірмеге ауысуға рұқсат етіледі ме. Бірақ әзірше қиындатпайық.

Брокер 3 желіден шығады, ал 2-брокерде 2-бөлімге жаңа көшбасшы сайланады.

Күріш. 2. Брокер 3 өледі және оның 2-брокердегі ізбасары 2-бөлімнің жаңа жетекшісі болып сайланды.

Содан кейін 1-брокер кетеді және 1-бөлім де өз көшбасшысын жоғалтады, оның рөлі 2-брокерге өтеді.

Күріш. 3. Бір брокер қалды. Барлық көшбасшылар нөлдік артықшылықпен бір брокерде

Брокер 1 желіге оралғанда, ол төрт ізбасарды қосады, бұл әрбір бөлімге біраз артықшылық береді. Бірақ барлық көшбасшылар 2-брокерде қалды.

Күріш. 4. Көшбасшылар 2-брокерде қалады

Брокер 3 келгенде, біз әр бөлімге үш көшірмеге ораламыз. Бірақ барлық көшбасшылар әлі де 2-брокерде.

Күріш. 5. 1 және 3 брокерлерді қалпына келтіргеннен кейін басшылардың теңгерімсіз орналасуы

Кафкада RabbitMQ-ға қарағанда көшбасшыны жақсырақ қайта теңестіруге арналған құрал бар. Мұнда көшу кезінде артық санын азайту арқылы негізгі түйінді тасымалдау саясаттарын өзгерткен үшінші тарап плагинін немесе сценарийін пайдалану керек болды. Бұған қоса, үлкен кезектер үшін синхрондау кезінде қолжетімсіздікті қабылдауға тура келді.

Кафкада жетекші рөлге арналған «артықшылықты көшірмелер» ұғымы бар. Тақырып бөлімдері жасалған кезде, Кафка көшбасшыларды түйіндер бойынша біркелкі таратуға әрекеттенеді және сол бірінші көшбасшыларды таңдаулы деп белгілейді. Уақыт өте келе сервердің қайта жүктелуіне, сәтсіздікке және қосылымның бұзылуына байланысты көшбасшылар жоғарыда сипатталған төтенше жағдайда сияқты басқа түйіндерде аяқталуы мүмкін.

Мұны түзету үшін Кафка екі нұсқаны ұсынады:

• Опция auto.leader.rebalance.enable=true контроллер түйініне жетекшілерді таңдаулы көшірмелерге автоматты түрде қайта тағайындауға және осылайша біркелкі таратуды қалпына келтіруге мүмкіндік береді.
• Әкімші сценарийді іске қоса алады kafka-preferred-replica-election.sh қолмен қайта тағайындау үшін.

Күріш. 6. Қайта теңестіруден кейінгі көшірмелер

Бұл сәтсіздіктің жеңілдетілген нұсқасы болды, бірақ мұнда тым күрделі ештеңе жоқ болса да, шындық күрделірек. Мұның бәрі синхрондалған көшірмелерге (In-Sync Replicas, ISR) келеді.

Синхрондалған көшірмелер (ISR)

ISR – «синхрондалған» (синхрондалған) деп саналатын бөлімнің көшірмелерінің жинағы. Көшбасшы бар, бірақ ізбасарлар болмауы мүмкін. Жазушы аралық мерзімі біткенге дейін көшбасшының барлық хабарламаларының дәл көшірмелерін жасаған болса, синхрондалған болып саналады. replica.lag.time.max.ms.

Жазушы ISR жиынынан жойылады, егер ол:

• интервалды таңдауға сұраныс жасаған жоқ replica.lag.time.max.ms (өлді деп болжануда)
• аралықта жаңарту мүмкін болмады replica.lag.time.max.ms (баяу деп саналады)

Бақылаушылар интервалда іріктеу сұрауларын жасайды replica.fetch.wait.max.ms, ол әдепкі бойынша 500 мс.

ISR мақсатын нақты түсіндіру үшін өндірушінің растауларын және кейбір сәтсіздік сценарийлерін қарау керек. Брокер растауды қашан жіберетінін өндірушілер таңдай алады:

• acks=0, растау жіберілмеді
• acks=1, растау көшбасшы өзінің жергілікті журналына хабарлама жазғаннан кейін жіберіледі
• acks=all, растау ISR-дегі барлық көшірмелер хабарламаны жергілікті журналдарға жазғаннан кейін жіберіледі

Кафка терминологиясында, егер ISR хабарламаны сақтаса, ол «міндеттелген» болып табылады. Acks=all - ең қауіпсіз опция, бірақ сонымен бірге қосымша кідіріс қосады. Сәтсіздіктің екі мысалын және әртүрлі «акциялар» опцияларының ISR тұжырымдамасымен қалай әрекеттесетінін қарастырайық.

Acks=1 және ISR

Бұл мысалда, егер көшбасшы барлық ізбасарлардың әрбір хабарламасының сақталуын күтпесе, көшбасшы сәтсіз болған жағдайда деректердің жоғалуы мүмкін екенін көреміз. Синхрондалмаған жазылушыға шарлау параметр арқылы қосуға немесе өшіруге болады таза емес.көшбасшы.сайлау.қосу.

Бұл мысалда өндіруші acks=1 мәніне ие. Бөлім барлық үш брокерлерге таратылады. Брокер 3 артта қалды, ол сегіз секунд бұрын көшбасшымен синхрондалған және қазір 7456 хабарламадан артта. Брокер 1 бір секунд қана артта қалды. Біздің продюсер хабарлама жібереді және көшбасшы күтпеген баяу немесе өлі ізбасарларының үстеме ақысынсыз тез жауап алады.

Күріш. 7. Үш репликасы бар ISR

Брокер 2 сәтсіз аяқталды және өндіруші қосылым қатесін алады. Көшбасшылық 1-брокерге өткеннен кейін біз 123 хабарды жоғалтамыз. 1-брокердегі ізбасар ISR бөлігі болды, бірақ ол құлаған кезде көшбасшымен толық синхрондалмаған.

Күріш. 8. Ол бұзылған кезде хабарлар жоғалады

Конфигурацияда bootstrap.servers Өндірушінің тізімде бірнеше брокерлері бар және жаңа бөлім басшысы болып табылатын басқа брокерден сұрай алады. Содан кейін ол 1-брокерге қосылым орнатады және хабарларды жіберуді жалғастырады.

Күріш. 9. Хабарламаларды жіберу қысқа үзілістен кейін жалғасады

Брокер 3 одан да артта қалды. Ол алу сұрауларын жасайды, бірақ синхрондау мүмкін емес. Бұл брокерлер арасындағы баяу желі қосылымына, сақтау мәселесіне және т.б. байланысты болуы мүмкін. Ол ISR-ден жойылған. Енді ISR бір көшірмеден тұрады - көшбасшы! Өндіруші хабарламалар жіберуді және растауларды алуды жалғастырады.

Күріш. 10. 3-брокердегі ізбасар ISR-ден жойылады

Брокер 1 төмендейді және көшбасшылық рөл 3 хабардың жоғалуымен 15286-брокерге ауысады! Өндіруші қосылым қатесі туралы хабарды алады. ISR-ден тыс көшбасшыға көшу тек орнатудың арқасында мүмкін болды unclean.leader.election.enable=true. Егер ол орнатылған болса жалған, онда ауысу орын алмайды және барлық оқу және жазу сұраулары қабылданбайды. Бұл жағдайда біз 1 брокердің көшірмедегі өзінің толық деректерімен оралуын күтеміз, ол қайтадан көшбасшылықты алады.

Күріш. 11. Брокер 1 құлайды. Сәтсіздік орын алған кезде хабарлардың көп саны жоғалады

Продюсер соңғы брокермен байланыс орнатып, оның қазір секция жетекшісі екенін көреді. Ол 3-брокерге хабарламалар жібере бастайды.

Күріш. 12. Қысқа үзілістен кейін хабарламалар қайтадан 0-бөлімге жіберіледі

Біз жаңа байланыстар орнату және жаңа көшбасшыны іздеу үшін қысқа үзілістерден басқа, өндіруші үнемі хабарламалар жіберетінін көрдік. Бұл конфигурация дәйектілік (деректер қауіпсіздігі) есебінен қолжетімділікті қамтамасыз етеді. Кафка мыңдаған хабарламаларды жоғалтты, бірақ жаңа жазбаларды қабылдауды жалғастырды.

Acks=all және ISR

Бұл сценарийді тағы қайталайық, бірақ acks=барлығы. 3-брокердің орташа кешігуі төрт секундты құрайды. Өндіруші хабарлама жібереді acks=барлығы, енді жылдам жауап алмайды. Көшбасшы хабардың ISR-дегі барлық көшірмелердің сақталуын күтеді.

Күріш. 13. Үш репликасы бар ISR. Біреуі баяу, соның салдарынан жазу кешігуі болады

Төрт секунд қосымша кешігуден кейін 2-брокер акті жібереді. Барлық көшірмелер енді толығымен жаңартылды.

Күріш. 14. Барлық көшірмелер хабарламаларды сақтайды және растау жібереді

Брокер 3 енді одан әрі артта қалып, ISR-ден жойылды. ISR-де баяу көшірмелер қалмағандықтан, кідіріс айтарлықтай төмендейді. Брокер 2 енді тек 1-брокерді күтеді және оның орташа 500 мс кешігуі бар.

Күріш. 15. 3-брокердегі көшірме ISR-ден жойылады

Содан кейін 2-брокер құлап, көшбасшылық хабарларды жоғалтпай 1-брокерге өтеді.

Күріш. 16. Брокер 2 құлады

Өндіруші жаңа көшбасшыны тауып, оған хабарламалар жібере бастайды. ISR енді бір көшірмеден тұратындықтан, кідіріс одан әрі азаяды! Сондықтан опция acks=барлығы артықшылықты қоспайды.

Күріш. 17. 1-брокердегі реплика хабарламаларды жоғалтпай жетекші орын алады

Содан кейін 1-брокер бұзылып, жетекші 3 хабарлама жоғалтып, 14238-брокерге өтеді!

Күріш. 18. Брокер 1 өледі және таза емес параметрмен көшбасшылық ауысу деректердің ауқымды жоғалуына әкеледі

Опцияны орната алмадық таза емес.көшбасшы.сайлау.қосу мағынаға шынайы. Әдепкі бойынша ол тең жалған. Параметрлер acks=барлығы с unclean.leader.election.enable=true кейбір қосымша деректер қауіпсіздігімен қол жетімділікті қамтамасыз етеді. Бірақ көріп отырғаныңыздай, біз әлі де хабарларды жоғалтуымыз мүмкін.

Бірақ деректер қауіпсіздігін арттырғымыз келсе ше? қоюға болады unclean.leader.election.enable = жалған, бірақ бұл бізді деректердің жоғалуынан міндетті түрде қорғамайды. Егер көшбасшы қатты құлап, деректерді өзімен бірге алса, хабарламалар әлі де жоғалады, сонымен қатар әкімші жағдайды қалпына келтірмейінше қолжетімділік жоғалады.

Барлық хабарлардың артық екеніне көз жеткізіп, жазбаны алып тастаған дұрыс. Содан кейін, кем дегенде, брокердің көзқарасы бойынша, деректердің жоғалуы екі немесе одан да көп бір уақытта сәтсіздіктер болған жағдайда ғана мүмкін болады.

Acks=all, min.insync.replicas және ISR

Тақырып конфигурациясымен min.insync.replicas Біз деректер қауіпсіздігінің деңгейін арттырамыз. Алдыңғы сценарийдің соңғы бөлігін қайталап көрейік, бірақ бұл жолы min.insync.replicas=2.

Осылайша, 2-брокерде көшірме жетекшісі бар және 3-брокердегі ізбасар ISR-ден жойылады.

Күріш. 19. Екі көшірмеден алынған ISR

2-брокер құлап, көшбасшылық хабарларды жоғалтпай 1-брокерге өтеді. Бірақ қазір ISR тек бір көшірмеден тұрады. Бұл жазбаларды қабылдаудың ең аз санына сәйкес келмейді, сондықтан брокер жазу әрекетіне қателікпен жауап береді NotEnoughReplicas.

Күріш. 20. ISR саны min.insync.replicas ішінде көрсетілгеннен бір төмен

Бұл конфигурация дәйектілік үшін қолжетімділікті құрбан етеді. Хабарламаны растамас бұрын оның кем дегенде екі көшірмеге жазылғанына көз жеткіземіз. Бұл өндірушіге әлдеқайда сенімділік береді. Бұл жерде хабардың жоғалуы хабар қосымша жазылушыға қайталанбайынша, қысқа аралықта бір уақытта екі реплика сәтсіз болған жағдайда ғана мүмкін болады, бұл екіталай. Бірақ егер сіз супер параноид болсаңыз, репликация коэффициентін 5-ке орнатуға болады және min.insync.replicas бойынша 3. Мұнда рекорд жоғалту үшін үш брокер бір уақытта құлауы керек! Әрине, сіз бұл сенімділік үшін қосымша кідіріс кезінде төлейсіз.

Деректер қауіпсіздігі үшін қол жетімділік қажет болғанда

Сонымен қатар RabbitMQ көмегімен жағдай, кейде деректер қауіпсіздігі үшін қол жетімділік қажет. Бұл туралы ойлану керек:

• Жариялаушы жай ғана қатені қайтарып, жоғары ағындық қызметке немесе пайдаланушыға кейінірек әрекетті қайталай алады ма?
• Баспагер кейінірек әрекетті қайталау үшін хабарды жергілікті түрде немесе дерекқорда сақтай ала ма?

Жауап жоқ болса, қолжетімділікті оңтайландыру деректер қауіпсіздігін жақсартады. Жазбаудың орнына қолжетімділікті таңдасаңыз, деректер азырақ жоғалады. Осылайша, бәрі тепе-теңдікті табуға байланысты және шешім нақты жағдайға байланысты.

ISR мағынасы

ISR жинағы деректер қауіпсіздігі мен кідіріс арасындағы оңтайлы теңгерімді таңдауға мүмкіндік береді. Мысалы, кідіріс тұрғысынан өлі немесе баяу көшірмелердің әсерін азайта отырып, репликалардың көпшілігі сәтсіз болған жағдайда қолжетімділікті қамтамасыз етіңіз.

Мағынаны өзіміз таңдаймыз replica.lag.time.max.ms қажеттіліктеріңізге сәйкес. Негізінде, бұл параметр біз қаншалықты кешіктіруді қашан қабылдауға дайын екенімізді білдіреді acks=барлығы. Әдепкі мән - он секунд. Егер бұл сізге тым ұзақ болса, оны азайтуға болады. Содан кейін ISR өзгерістерінің жиілігі артады, өйткені ізбасарлар жойылады және жиі қосылады.

RabbitMQ - бұл көшіруді қажет ететін айналар жиынтығы. Баяу айналар қосымша кідіріс береді, ал өлі айналар әрбір түйіннің қолжетімділігін тексеретін пакеттер жауап бергенше күте алады. ISR - бұл кідіріс мәселелерін болдырмаудың қызықты жолы. Бірақ біз резервтен айырылу қаупі бар, өйткені ISR тек көшбасшыға дейін қысқарады. Бұл қауіпті болдырмау үшін параметрді пайдаланыңыз min.insync.replicas.

Клиентке қосылу кепілдігі

Параметрлерде bootstrap.servers өндіруші мен тұтынушы клиенттерді қосу үшін бірнеше брокерлерді көрсете алады. Идея мынада: бір түйін төмендеген кезде, клиент қосылымды аша алатын бірнеше қосалқылары қалады. Бұл міндетті түрде бөлім жетекшілері емес, жай ғана бастапқы жүктеуге арналған трамплин. Клиент олардан оқу/жазу бөлімінің көшбасшысын орналастыратын түйінді сұрай алады.

RabbitMQ-де клиенттер кез келген түйінге қосыла алады, ал ішкі маршруттау сұрауды бару керек жерге жібереді. Бұл RabbitMQ алдында жүктеме балансын орнатуға болатындығын білдіреді. Кафка клиенттерден сәйкес бөлім көшбасшысын орналастыратын түйінге қосылуды талап етеді. Мұндай жағдайда жүктеме теңестіргішті орнату мүмкін емес. Тізім bootstrap.servers Клиенттердің сәтсіздіктен кейін дұрыс түйіндерге қол жеткізуі және таба алуы өте маңызды.

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

Осы уақытқа дейін біз кластердің брокердің құлауы туралы қалай білетінін және жаңа басшының қалай сайланғанын қарастырған жоқпыз. Кафка желі бөлімдерімен қалай жұмыс істейтінін түсіну үшін алдымен консенсус архитектурасын түсіну керек.

Әрбір Кафка кластері Zookeeper кластерімен бірге орналастырылған, ол жүйеге белгілі бір күй бойынша консенсусқа қол жеткізуге мүмкіндік беретін, қолжетімділіктен гөрі жүйелілікке басымдық беретін бөлінген консенсус қызметі. Оқу және жазу әрекеттерін мақұлдау үшін Zookeeper түйіндерінің көпшілігінің келісімі қажет.

Zookeeper кластердің күйін сақтайды:

• Тақырыптар тізімі, бөлімдер, конфигурация, ағымдағы жетекші көшірмелері, таңдаулы көшірмелер.
• Кластер мүшелері. Әрбір брокер Zookeeper кластерін тексереді. Белгіленген уақыт ішінде ол пинг алмаса, Zookeeper брокерді қолжетімсіз деп жазады.
• Контроллер үшін негізгі және қосалқы түйіндерді таңдау.

Контроллер түйіні реплика жетекшілерін сайлауға жауапты Кафка брокерлерінің бірі болып табылады. Zookeeper контроллерге кластер мүшелігі және тақырып өзгерістері туралы хабарландырулар жібереді және контроллер осы өзгерістер бойынша әрекет етуі керек.

Мысалы, он бөлімді және репликация коэффициенті 3-ке тең жаңа тақырыпты алайық. Контроллер брокерлер арасында көшбасшыларды оңтайлы бөлуге тырысып, әрбір бөлім үшін көшбасшы таңдауы керек.

Әрбір бөлім контроллері үшін:

• ISR және көшбасшы туралы Zookeeper ақпаратын жаңартады;
• Осы бөлімнің көшірмесін орналастыратын әрбір брокерге LeaderAndISR пәрменін жібереді, брокерлерді ISR және көшбасшы туралы хабардар етеді.

Көшбасшысы бар брокер құлаған кезде зоопарк бақылаушыға хабарлама жібереді және ол жаңа басшыны сайлайды. Тағы да, контроллер алдымен Zookeeper-ді жаңартады, содан кейін әрбір брокерге басшылықтың өзгеруі туралы хабардар ететін пәрмен жібереді.

Әрбір басшы ISR жалдауға жауапты. Параметрлер replica.lag.time.max.ms ол жерге кім кіретінін анықтайды. ISR өзгерген кезде көшбасшы жаңа ақпаратты Zookeeper-ге жібереді.

Хайуанаттар бағының қызметкері кез келген өзгерістер туралы әрқашан хабардар болады, осылайша сәтсіздікке ұшыраған жағдайда басшылық жаңа басшыға оңай ауысады.

Күріш. 21. Кафка консенсус

Репликация протоколы

Репликацияның мәліметтерін түсіну ықтимал деректерді жоғалту сценарийлерін жақсырақ түсінуге көмектеседі.

Іріктеу сұраулары, Log End Offset (LEO) және Highwater Mark (HW)

Біз ізбасарлар көшбасшыға мерзімді түрде алу сұрауларын жіберетінін қарастырдық. Әдепкі интервал - 500 мс. Бұл RabbitMQ-дан айырмашылығы, RabbitMQ-те репликация кезек айнасынан емес, шеберден басталады. Шебер айнадағы өзгерістерді итереді.

Көшбасшы және барлық ізбасарлар Log End Offset (LEO) және Highwater (HW) белгісін сақтайды. LEO белгісі соңғы хабарламаның ығысуын жергілікті көшірмеде сақтайды, ал HW соңғы тапсырманың ығысуын сақтайды. Орындау күйі үшін хабар барлық ISR репликаларында сақталуы керек екенін есте сақтаңыз. Бұл LEO әдетте HW-ден сәл алда екенін білдіреді.

Көшбасшы хабарлама алған кезде оны жергілікті түрде сақтайды. Жазушы өзінің LEO-сын жіберу арқылы алу сұрауын жасайды. Содан кейін көшбасшы осы LEO-дан басталатын хабарламалар партиясын жібереді, сонымен қатар ағымдағы HW жібереді. Лидер барлық көшірмелердің хабарламаны берілген ығысуда сақтағаны туралы ақпаратты алған кезде, ол HW белгісін жылжытады. Тек көшбасшы ғана HW жылжыта алады, сондықтан барлық ізбасарлар олардың сұрауларына жауаптардағы ағымдағы мәнді білетін болады. Бұл ізбасарлар хабарламада да, HW білімінде де көшбасшыдан артта қалуы мүмкін дегенді білдіреді. Тұтынушылар хабарларды тек ағымдағы HW дейін алады.

«Тұрақты» дискіге емес, жадқа жазылғанын білдіреді. Өнімділік үшін Кафка белгілі бір аралықта дискімен синхрондалады. RabbitMQ-де де осындай интервал бар, бірақ ол басшыға және барлық айналар хабарламаны дискіге жазғаннан кейін ғана растауды жібереді. Кафка әзірлеушілері өнімділік себептеріне байланысты хабарлама жадқа жазылған бойда акті жіберуге шешім қабылдады. Кафка артықшылық танылған хабарламаларды тек жадта қысқаша сақтау қаупін өтейтін ставкалар.

Көшбасшының сәтсіздігі

Көшбасшы құлаған кезде зоопарк бақылаушыға хабарлайды және ол жаңа көшбасшы репликасын таңдайды. Жаңа көшбасшы өзінің LEO сәйкес жаңа HW белгісін белгілейді. Содан кейін жазылушылар жаңа көшбасшы туралы ақпарат алады. Кафка нұсқасына байланысты ізбасар екі сценарийдің бірін таңдайды:

1. Ол жергілікті журналды белгілі HW-ге қысқартады және осы белгіден кейін хабарлар алу үшін жаңа көшбасшыға сұрау жібереді.
2. Көшбасшыға көшбасшы болып сайланған кездегі ЖҚБ-ны білу үшін сұрау жібереді, содан кейін журналды осы офсетке қысқартады. Содан кейін ол осы ығысудан бастап мерзімді алу сұрауларын жасай бастайды.

Жазушы келесі себептерге байланысты журналды қысқартуы мүмкін:

• Көшбасшы сәтсіз болғанда, Zookeeper-те тіркелген ISR жинағындағы бірінші ізбасар сайлауда жеңіп, көшбасшы болады. ISR-дегі барлық жазылушылар «синхрондалған» деп есептелсе де, бұрынғы көшбасшыдан барлық хабарлардың көшірмелерін алмаған болуы мүмкін. Таңдаулы ізбасарда ең соңғы көшірме болмауы әбден мүмкін. Кафка репликалар арасында алшақтық жоқтығын қамтамасыз етеді. Осылайша, сәйкессіздіктерді болдырмау үшін әрбір ізбасар өз журналын жаңа көшбасшының сайланған кездегі HW мәніне қысқарту керек. Бұл орнатудың тағы бір себебі acks=барлығы бірізділік үшін өте маңызды.
• Хабарламалар мерзімді түрде дискіге жазылады. Барлық кластер түйіндері бір уақытта сәтсіздікке ұшыраса, дискілерде әртүрлі ығысулары бар репликалар сақталады. Брокерлер желіге қайта оралғанда, сайланған жаңа көшбасшы ізбасарларының артында болуы мүмкін, себебі ол басқалардан бұрын дискіге сақталған.

Кластермен қайта қосылу

Кластерге қайта қосылған кезде көшірмелер көшбасшының сәтсіздігімен бірдей әрекет жасайды: олар көшбасшының репликасын тексереді және журналын оның HW (сайлау кезінде) қысқартады. Салыстыру үшін, RabbitMQ қайта біріктірілген түйіндерді мүлдем жаңа деп санайды. Екі жағдайда да брокер бар күйді жояды. Автоматты синхрондау пайдаланылса, шебер «бүкіл әлем күтсін» әдісімен жаңа айнаға барлық ағымдағы мазмұнды қайталауы керек. Мастер бұл әрекет кезінде оқу немесе жазу әрекеттерін қабылдамайды. Бұл тәсіл үлкен кезектерде қиындықтар туғызады.

Кафка таратылған журнал болып табылады және жалпы ол деректер оқылғаннан кейін кезектен жойылатын RabbitMQ кезегіне қарағанда көбірек хабарларды сақтайды. Белсенді кезектер салыстырмалы түрде аз болуы керек. Бірақ Кафка - бұл күндер немесе апталар кезеңін белгілей алатын өзінің сақтау саясаты бар журнал. Кезекті блоктау және толық синхрондау тәсілі таратылған журнал үшін мүлдем қолайсыз. Оның орнына, Кафка ізбасарлары, егер олардың көшірмелері көшбасшыдан озып кетсе, журналды көшбасшының HW-ге (ол сайланған кезде) қысқартады. Ықтимал жағдайда, ізбасар артта қалғанда, ол жай ғана ағымдағы LEO-дан бастап алу сұрауларын жасай бастайды.

Жаңа немесе қайта қосылған жазылушылар ISR шегінен тыс басталады және міндеттемелерге қатыспайды. Олар топпен бірге жұмыс істейді, олар көшбасшыны қуып жетіп, ISR-ге кірмейінше, хабарламаларды мүмкіндігінше тез қабылдайды. Құлыптау жоқ және барлық деректеріңізді тастаудың қажеті жоқ.

Байланыстың жоғалуы

Кафкада RabbitMQ-ға қарағанда көбірек құрамдас бөліктер бар, сондықтан кластер ажыратылған кезде оның мінез-құлқының күрделі жиынтығы бар. Бірақ Кафка бастапқыда кластерлерге арналған, сондықтан шешімдер өте жақсы ойластырылған.

Төменде бірнеше қосылым сәтсіздігі сценарийлері берілген:

• 1-жағдаят: Ізбасар көшбасшыны көрмесе де, хайуанаттар бағындаушыны көреді.
• 2-жағдаят: Көшбасшы ешқандай ізбасарларды көрмесе де, зоопаркты көреді.
• 3-жағдаят: Ізбасар көшбасшыны көреді, бірақ хайуанаттар бағындаушыны көрмейді.
• Сценарий 4. Көшбасшы ізбасарларды көреді, бірақ хайуанаттар бағындаушыны көрмейді.
• 5-сценарий: ізбасар басқа Кафка түйіндерінен де, Zookeeper-ден де толығымен бөлек.
• 6-сценарий: Көшбасшы басқа Кафка түйіндерінен де, Zookeeper-ден де мүлдем бөлек.
• 7-сценарий: Кафка контроллері түйіні басқа Кафка түйінін көре алмайды.
• 8-сценарий: Кафка контроллері Zookeeper қолданбасын көрмейді.

Әрбір сценарийдің өз мінез-құлқы бар.

1-жағдаят: Ізбасар көшбасшыны көрмейді, бірақ зоопаркты көреді

Күріш. 22. 1-сценарий: үш көшірменің ISR

Байланыс ақауы 3-брокерді 1 және 2 брокерлерден бөледі, бірақ Zookeeper-ден емес. Брокер 3 енді алу сұрауларын жібере алмайды. Уақыт өткен соң replica.lag.time.max.ms ол ISR-ден жойылады және хабарламаларды қабылдауға қатыспайды. Байланыс қалпына келтірілгеннен кейін ол сұрауларды алуды жалғастырады және көшбасшыны қуып жеткенде ISR-ге қосылады. Zookeeper пингтерді алуды жалғастырады және брокер тірі және жақсы деп есептейді.

Күріш. 23. 1-сценарий: replica.lag.time.max.ms интервалында одан алу сұрауы алынбаса, брокер ISR-ден жойылады.

RabbitMQ сияқты бөлінетін ми немесе түйін суспензиясы жоқ. Оның орнына артықшылық азаяды.

2-жағдаят: Көшбасшы ешқандай ізбасарларды көрмесе де, зоопаркты көреді

Күріш. 24. Сценарий 2. Көшбасшы және екі ізбасар

Желі байланысының бұзылуы көшбасшыны ізбасарлардан бөледі, бірақ брокер Zookeeper-ді әлі де көре алады. Бірінші сценарийдегідей, ISR қысқарады, бірақ бұл жолы тек көшбасшыға ғана беріледі, өйткені барлық ізбасарлар алу сұрауларын жіберуді тоқтатады. Тағы да, логикалық бөлу жоқ. Оның орнына қосылым қалпына келгенше жаңа хабарлар үшін артықшылық жоғалады. Zookeeper пингтерді алуды жалғастыруда және брокер тірі және жақсы деп санайды.

Күріш. 25. Сценарий 2. ISR тек көшбасшыға дейін қысқарды

Сценарий 3. Ізбасар көшбасшыны көреді, бірақ хайуанаттар бағындаушыны көрмейді

Ізбасар Zookeeper-ден бөлінеді, бірақ көшбасшысы бар брокерден емес. Нәтижесінде, ізбасар алу сұрауларын жасауды және ISR мүшесі болуды жалғастырады. Zookeeper енді пингтерді қабылдамайды және брокердің бұзылуын тіркемейді, бірақ ол тек ізбасар болғандықтан, қалпына келтіруден кейін ешқандай салдары болмайды.

Күріш. 26. 3-жағдай: ізбасар көшбасшыға сұрауларды жіберуді жалғастырады

Сценарий 4. Көшбасшы ізбасарларды көреді, бірақ зоопаркті көрмейді

Күріш. 27. Сценарий 4. Көшбасшы және екі ізбасар

Көшбасшы зоопарктан бөлінген, бірақ ізбасарлары бар брокерлерден емес.

Күріш. 28. 4-сценарий: Хайуанаттар бағындаушыдан оқшауланған көшбасшы

Біраз уақыттан кейін Zookeeper брокердің қатесін тіркейді және бұл туралы контроллерге хабарлайды. Ол ізбасарларының арасынан жаңа басшы сайлайды. Дегенмен, бастапқы көшбасшы өзін көшбасшы деп ойлауды жалғастырады және жазбаларды қабылдауды жалғастырады acks=1. Жазушылар бұдан былай оған алу сұрауларын жібермейді, сондықтан ол оларды өлі деп санайды және ISR-ді өзіне қысқартуға тырысады. Бірақ оның Zookeeper-пен байланысы болмағандықтан, ол мұны істей алмайды және сол кезде басқа жазбаларды қабылдаудан бас тартады.

хабарлар acks=барлығы растауды алмайды, себебі ISR алдымен барлық көшірмелерді қосады және хабарлар оларға жетпейді. Бастапқы көшбасшы оларды ISR-ден алып тастауға тырысқанда, ол мұны істей алмайды және кез келген хабарларды қабылдауды мүлдем тоқтатады.

Клиенттер көп ұзамай көшбасшының өзгеруін байқап, жазбаларды жаңа серверге жібере бастайды. Желіні қалпына келтіргеннен кейін, бастапқы көшбасшы оның бұдан былай көшбасшы емес екенін көреді және журналдың алшақтығын болдырмау үшін жаңа көшбасшының сәтсіздікке ұшыраған кездегі HW мәніне журналын қысқартады. Содан кейін ол жаңа жетекшіге алу сұрауларын жібере бастайды. Бастапқы көшбасшыдан жаңа көшбасшыға қайталанбаған барлық жазбалар жоғалады. Яғни, екі басшы жұмыс істеген бірнеше секундта бастапқы көшбасшы мойындамаған хабарламалар жоғалады.

Күріш. 29. Сценарий 4. 1-брокердегі көшбасшы желі қалпына келтірілгеннен кейін ізбасарға айналады.

5-сценарий: ізбасар басқа Кафка түйіндерінен де, Zookeeper-ден де толығымен бөлек

Ізбасар басқа Кафка түйіндерінен де, Zookeeperден де толығымен оқшауланған. Ол желі қалпына келтірілгенге дейін өзін ISR-ден алып тастайды, содан кейін басқаларды қуып жетеді.

Күріш. 30. 5-жағдай: Оқшауланған ізбасар ISR-ден жойылады

6-сценарий: Көшбасшы басқа Кафка түйіндерінен де, Zookeeper-ден де мүлдем бөлек

Күріш. 31. Сценарий 6. Көшбасшы және екі ізбасар

Көшбасшы өзінің ізбасарларынан, бақылаушыдан және зоопарктан толығымен оқшауланған. Қысқа мерзім ішінде ол жазбаларды қабылдауды жалғастырады acks=1.

Күріш. 32. Сценарий 6: Көшбасшыны басқа Kafka және Zookeeper түйіндерінен оқшаулау

Сұраныстардың мерзімі өткеннен кейін қабылданбауы replica.lag.time.max.ms, ол ISR-ді өзіне қысқартуға тырысады, бірақ Zookeeper-пен байланыс болмағандықтан мұны істей алмайды, содан кейін ол жазуларды қабылдауды тоқтатады.

Сонымен қатар, зоопаркшы оқшауланған брокерді өлі деп белгілейді және контроллер жаңа басшыны сайлайды.

Күріш. 33. Сценарий 6. Екі көшбасшы

Бастапқы көшбасшы жазбаларды бірнеше секундқа қабылдауы мүмкін, бірақ содан кейін кез келген хабарларды қабылдауды тоқтатады. Клиенттер әр 60 секунд сайын соңғы метадеректермен жаңартылып отырады. Олар көшбасшының ауысуы туралы хабардар болады және жаңа басшыға жазбалар жібере бастайды.

Күріш. 34. 6-жағдай: Өндірушілер жаңа көшбасшыға ауысады

Байланыс жоғалғаннан кейін бастапқы жетекші жасаған барлық расталған жазбалар жоғалады. Желі қалпына келтірілгеннен кейін, бастапқы көшбасшы Zookeeper арқылы оның бұдан былай көшбасшы емес екенін анықтайды. Содан кейін ол журналды сайлау кезінде жаңа басшының HW қызметіне қысқартады және ізбасар ретінде сұрауларды жібере бастайды.

Күріш. 35. 6-жағдай: желі қосылымы қалпына келтірілгеннен кейін бастапқы көшбасшы ізбасарға айналады

Бұл жағдайда логикалық бөліну қысқа мерзімге орын алуы мүмкін, бірақ тек егер acks=1 и min.insync.replicas сондай-ақ 1. Логикалық бөлу автоматты түрде желі қалпына келтірілгеннен кейін, бастапқы көшбасшы өзінің көшбасшы емес екенін түсінгенде немесе барлық клиенттер көшбасшының өзгергенін түсініп, жаңа көшбасшыға жаза бастағанда - қайсысы бірінші орын алса, автоматты түрде аяқталады. Кез келген жағдайда, кейбір хабарламалар жоғалады, бірақ тек acks=1.

Бұл сценарийдің тағы бір нұсқасы бар, онда желі бөліну алдында ізбасарлар артта қалып, көшбасшы ISR-ді өзіне ғана қысты. Содан кейін ол байланыс жоғалуына байланысты оқшауланады. Жаңа басшы сайланады, бірақ бастапқы көшбасшы тіпті жазбаларды қабылдауды жалғастырады acks=барлығы, өйткені ISR-де одан басқа ешкім жоқ. Бұл жазбалар желі қалпына келтірілгеннен кейін жойылады. Бұл опцияны болдырмаудың жалғыз жолы min.insync.replicas = 2.

7-сценарий: Кафка контроллері түйіні басқа Кафка түйінін көре алмайды

Жалпы алғанда, Кафка түйінімен байланыс үзілгеннен кейін контроллер оған көшбасшының өзгеруі туралы ақпаратты жібере алмайды. Ең нашар жағдайда, бұл 6-сценарийдегідей қысқа мерзімді логикалық ажырасуға әкеледі. Көбінесе, соңғысы сәтсіз болса, брокер көшбасшылыққа үміткер бола алмайды.

8-сценарий: Кафка контроллері Zookeeper қолданбасын көрмейді

Zookeeper құлаған контроллерден пинг алмайды және контроллер ретінде жаңа Кафка түйінін таңдайды. Түпнұсқа контроллер өзін осылай көрсетуді жалғастыра алады, бірақ ол Zookeeper-ден хабарландыруларды алмайды, сондықтан оның орындайтын тапсырмалары болмайды. Желі қалпына келтірілгеннен кейін ол енді контроллер емес, кәдімгі Кафка түйініне айналғанын түсінеді.

Сценарийлерден қорытындылар

Біз ізбасар қосылымының жоғалуы хабардың жоғалуына әкелмейтінін көреміз, бірақ желі қалпына келтірілгенге дейін резервті уақытша азайтады. Бұл, әрине, бір немесе бірнеше түйіндер жоғалса, деректердің жоғалуына әкелуі мүмкін.

Байланыстың жоғалуына байланысты көшбасшы Zookeeper-тен бөлініп кетсе, бұл хабарлардың жоғалуына әкелуі мүмкін. acks=1. Zookeeper-пен байланыстың болмауы екі жетекшінің қысқаша логикалық бөлінуіне әкеледі. Бұл мәселе параметр арқылы шешіледі acks=барлығы.

Параметр min.insync.replicas екі немесе одан да көп көшірмелерге осындай қысқа мерзімді сценарийлер 6-сценарийдегідей жоғалған хабарларға әкелмейтініне қосымша кепілдік береді.

Жоғалған хабарламалардың қысқаша мазмұны

Кафкадағы деректерді жоғалтудың барлық жолдарын тізіп көрейік:

• Хабарламалар арқылы расталса, кез келген жетекші сәтсіздігі acks=1
• Көшбасшылықтың кез келген таза емес ауысуы, яғни ISR-ден тыс ізбасарға, тіпті бар acks=барлығы
• Хабарламалар расталған болса, көшбасшыны Zookeeper-ден оқшаулау acks=1
• ISR тобын өзіне дейін қысқартқан көшбасшының толық оқшаулануы. Барлық хабарлар тіпті жоғалады acks=барлығы. Бұл тек егер min.insync.replicas=1.
• Барлық бөлім түйіндерінің бір мезгілде істен шығуы. Хабарламалар жадтан қабылданатындықтан, кейбіреулері әлі дискіге жазылмауы мүмкін. Серверлерді қайта жүктегеннен кейін кейбір хабарлар жоқ болуы мүмкін.

Көшбасшылықтың таза емес ауысуын оларға тыйым салу немесе кем дегенде екі жұмыстан босатуды қамтамасыз ету арқылы болдырмауға болады. Ең берік конфигурация комбинация болып табылады acks=барлығы и min.insync.replicas 1 артық.

RabbitMQ және Кафка сенімділігін тікелей салыстыру

Сенімділік пен жоғары қолжетімділікті қамтамасыз ету үшін екі платформа да негізгі және қосымша репликация жүйесін жүзеге асырады. Дегенмен, RabbitMQ-де Ахиллес өкшесі бар. Сәтсіздіктен кейін қайта қосылған кезде түйіндер өз деректерін жояды және синхрондау блокталады. Бұл екі жақты толқу RabbitMQ-дегі үлкен кезектердің ұзақ өмір сүруіне күмән тудырады. Сізге қысқартылған резервтеу немесе ұзақ блоктау уақыттарын қабылдау қажет болады. Артықшылықты азайту деректердің үлкен жоғалу қаупін арттырады. Бірақ егер кезектер аз болса, артық болу үшін қайталанатын қосылу әрекеттерінің көмегімен қысқа қолжетімсіздік кезеңдерін (бірнеше секунд) шешуге болады.

Кафкада мұндай проблема жоқ. Ол деректерді көшбасшы мен ізбасар арасындағы алшақтық нүктесінен ғана алып тастайды. Барлық ортақ деректер сақталады. Сонымен қатар, репликация жүйені блоктамайды. Жаңа ізбасар қуып жеткенше, көшбасшы жазбаларды қабылдауды жалғастырады, сондықтан девоптар үшін кластерге қосылу немесе қайта қосылу тривиальды тапсырмаға айналады. Әрине, репликация кезінде желінің өткізу қабілеті сияқты мәселелер әлі де бар. Бір уақытта бірнеше ізбасарларды қоссаңыз, өткізу қабілеті шектеуіне тап болуыңыз мүмкін.

RabbitMQ кластердегі бірнеше серверлер бір уақытта істен шыққан кезде сенімділік жағынан Кафкадан жоғары. Жоғарыда айтқанымыздай, RabbitMQ хабарламаны дискіге басты және барлық айналар жазғаннан кейін ғана баспагерге растауды жібереді. Бірақ бұл екі себеп бойынша қосымша кідіріс қосады:

• fsync бірнеше жүз миллисекунд сайын
• Айнаның істен шығуы әрбір түйіннің қолжетімділігін тексеретін пакеттердің қызмет ету мерзімі өткеннен кейін ғана байқалуы мүмкін (таза белгі). Егер айна баяуласа немесе құласа, бұл кідіріс қосады.

Кафканың бәс тігуі мынада, егер хабарлама бірнеше түйіндерде сақталса, ол хабарларды жадқа түскен бойда мойындай алады. Осыған байланысты кез келген түрдегі хабарламаларды жоғалту қаупі бар (тіпті acks=барлығы, min.insync.replicas=2) бір уақытта істен шыққан жағдайда.

Жалпы алғанда, Кафка бағдарламалық жасақтаманың жақсы өнімділігін көрсетеді және кластерлер үшін басынан бастап жасалған. Сенімділік үшін қажет болса, ізбасарлар санын 11-ге дейін арттыруға болады. 5-репликация факторы және синхрондаудағы көшірмелердің ең аз саны min.insync.replicas=3 хабарды жоғалту өте сирек оқиғаға айналдырады. Егер сіздің инфрақұрылымыңыз осы репликация коэффициентін және артықшылық деңгейін қолдаса, онда осы опцияны таңдауға болады.

RabbitMQ кластерлері шағын кезектер үшін жақсы. Бірақ трафик көп болған кезде кішкентай кезектердің өзі тез өсуі мүмкін. Кезектер үлкен болғаннан кейін, қолжетімділік пен сенімділік арасында қиын таңдау жасауға тура келеді. RabbitMQ кластерленуі RabbitMQ икемділігінің артықшылықтары кластерлеудің кез келген кемшіліктерінен басым болатын әдеттегі емес жағдайлар үшін ең қолайлы.

RabbitMQ-ның үлкен кезектердегі осалдығына қарсы бір антидот - оларды көптеген кішігірім кезектерге бөлу. Егер сіз бүкіл кезекке толық тапсырыс беруді қажет етпесеңіз, бірақ тек сәйкес хабарламаларды (мысалы, белгілі бір клиенттің хабарламалары) немесе мүлдем тапсырыс бермесеңіз, онда бұл опция қолайлы: менің жобамды қараңыз Қайта теңестіруші кезекті бөлу (жоба әлі бастапқы кезеңде).

Соңында, RabbitMQ мен Кафканың кластерлеу және репликация механизмдеріндегі бірқатар қателер туралы ұмытпаңыз. Уақыт өте келе жүйелер жетілген және тұрақты болды, бірақ ешбір хабар жоғалудан 100% қауіпсіз болмайды! Сонымен қатар, деректер орталықтарында үлкен апаттар орын алады!

Егер мен бірдеңені жіберіп алсам, қателессем немесе кез келген тармақпен келіспесеңіз, пікір қалдырыңыз немесе маған хабарласыңыз.

Маған жиі сұрақ қояды: «Нені таңдау керек, Кафка немесе RabbitMQ?», «Қай платформа жақсы?». Шындық мынада, бұл шынымен сіздің жағдайыңызға, ағымдағы тәжірибеңізге және т.б. байланысты. Мен өз пікірімді айтудан тартынамын, өйткені барлық пайдалану жағдайлары мен ықтимал шектеулер үшін бір платформаны ұсыну тым жеңілдеу болар еді. Мен бұл мақалалар топтамасын сіз өз пікіріңізді қалыптастыруыңыз үшін жаздым.

Екі жүйе де осы салада көшбасшы екенін айтқым келеді. Мен аздап бейтарап болуым мүмкін, өйткені жобалармен тәжірибемнен хабардың кепілдендірілген тәртібі мен сенімділігі сияқты нәрселерді бағалаймын.

Мен мұндай сенімділік пен кепілдендірілген тапсырыссыз басқа технологияларды көремін, содан кейін мен RabbitMQ мен Кафкаға қарап, осы екі жүйенің де керемет құндылығын түсінемін.

Ақпарат көзі: www.habr.com