В акыркы макала каталарга сабырдуулук жана жогорку жеткиликтүүлүк үчүн 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-section.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=бардыгы жана 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деги маалыматты жаңыртат;
• Бул бөлүмдүн репликасын камтыган ар бир брокерге LeaderAndISRCommand жөнөтөт, брокерлерге 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. Лидер болуп шайланган убактагы HW билүү үчүн лидерге суроо-талап жөнөтөт, андан кийин журналды ушул офсетке кыскартат. Андан кийин ал ушул офсеттен баштап мезгил-мезгили менен алуу сурамдарын жасай баштайт.

Жолдоочу төмөнкү себептерден улам журналды кыскартууга туура келиши мүмкүн:

• Лидер ийгиликсиз болгондо, 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. Жолдоочу лидерди көрөт, бирок зоопаркты көрбөйт

Жолдоочу зоопарктан бөлүнөт, бирок лидер менен брокерден эмес. Натыйжада, жолдоочу алуу өтүнүчтөрүн жасап, ISR мүчөсү болууну улантат. Zookeeper мындан ары пингдерди кабыл албайт жана брокердин бузулушун каттабайт, бирок ал жөн гана жолдоочу болгондуктан, калыбына келтирилгенден кийин эч кандай кесепеттер болбойт.

Райс. 26. 3-сценарий: Жолдоочу лидерге алып келүү өтүнүчтөрүн жөнөтүүнү улантууда

4-сценарий. Лидер жолдоочуларды көрөт, бирок зоопаркты көрбөйт

Күрүч. 27. Сценарий 4. Лидер жана эки жолдоочу

Лидер зоопарктан бөлүнгөн, бирок жолдоочулары бар брокерлерден эмес.

Райс. 28. 4-сценарий: зоопарктан обочолонгон лидер

Бир нече убакыт өткөндөн кийин зоопарктын кызматкери брокердин катасын каттайт жана бул тууралуу контроллерге кабарлайт. Ал өзүнүн жолдоочуларынын арасынан жаңы лидерди тандайт. Бирок, баштапкы лидер лидер деп ойлой берет жана андан жазууларды кабыл ала берет 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=бардыгы
• Эгер билдирүүлөр колдонуу менен тастыкталса, лидерди зоопарктан обочолонтуу acks=1
• ISR тобун өзүнө чейин кыскарткан лидердин толук изоляциясы. Бардык билдирүүлөр, ал тургай, жоголот acks=бардыгы. Бул туура, эгерде min.insync.replicas=1.
• Бардык бөлүү түйүндөрүнүн бир эле убакта бузулушу. Билдирүүлөр эстутумдан кабыл алынгандыктан, айрымдары дискке жазыла элек болушу мүмкүн. Серверлерди кайра жүктөгөндөн кийин, кээ бир билдирүүлөр жок болушу мүмкүн.

Жетекчиликтин таза эмес өтүшүнө тыюу салуу же жок эле дегенде эки жумуштан бошотуу менен жол бербөөгө болот. Эң туруктуу конфигурация - бул айкалыштыруу acks=бардыгы и min.insync.replicas 1ден жогору.

RabbitMQ жана Kafka ишенимдүүлүгүн түз салыштыруу

Ишенимдүүлүктү жана жогорку жеткиликтүүлүктү камсыз кылуу үчүн эки платформа тең негизги жана экинчилик репликация системасын ишке ашырат. Бирок, RabbitMQда Ахиллес согончогу бар. Катадан кийин кайра туташканда түйүндөр өз маалыматтарын ташташат жана синхрондоштуруу бөгөттөлөт. Бул кош кагылышуу RabbitMQдагы чоң кезектердин узактыгына шек туудурат. Сиз кыскартылган ашыкча же узак бөгөттөө убакыттарын кабыл алышыңыз керек. Артыкчылыкты азайтуу массалык маалымат жоготуу коркунучун жогорулатат. Бирок, эгерде кезектер аз болсо, анда ашыкча болуу үчүн, кыска мөөнөттүү жеткиликсиздикти (бир нече секунда) кайталап туташуу аракеттери менен чечүүгө болот.

Кафкада мындай көйгөй жок. Ал лидер менен жолдоочунун ортосундагы айырмачылыктар боюнча гана маалыматтарды жокко чыгарат. Бардык бөлүшүлгөн дайындар сакталат. Мындан тышкары, репликация системаны бөгөттөбөйт. Жаңы жолдоочу жеткенде лидер постторду кабыл алууну улантат, андыктан девоптор үчүн кластерге кошулуу же кайра кошулуу арзыбаган иш болуп калат. Албетте, репликация учурунда тармактын өткөрүү жөндөмдүүлүгү сыяктуу маселелер дагы эле бар. Эгер бир эле учурда бир нече жолдоочуларды кошсоңуз, өткөрүү жөндөмдүүлүгүнүн чегине туш болушуңуз мүмкүн.

Кластердеги бир нече серверлер бир убакта иштебей калганда, RabbitMQ ишенимдүүлүгү боюнча Кафкадан жогору турат. Жогоруда айтылгандай, RabbitMQ билдирүү кожоюну жана бардык күзгүлөр тарабынан дискке жазылгандан кийин гана жарыялоочуга ырастоо жөнөтөт. Бирок бул эки себеп менен кошумча күтүү убактысын кошот:

• fsync ар бир нече жүз миллисекундда
• Күзгүнүн иштебей калышын ар бир түйүндүн (таза кененин) болушун текшерген пакеттердин иштөө мөөнөтү аяктагандан кийин гана байкаса болот. Күзгү басаңдаса же кулап кетсе, бул кечигүүнү кошот.

Кафканын коюму, эгер билдирүү бир нече түйүндөрдө сакталса, ал билдирүүлөр эстутумга тийген замат аларды тааный алат. Ушундан улам, ар кандай түрдөгү билдирүүлөрдү жоготуу коркунучу бар (ал тургай acks=бардыгы, min.insync.replicas=2) бир эле учурда бузулган учурда.

Жалпысынан алганда, Кафка программалык камсыздоонун жакшыраак иштешин көрсөтөт жана кластерлер үчүн башынан баштап иштелип чыккан. Ишенимдүүлүк үчүн зарыл болсо, жолдоочуларынын саны 11ге чейин көбөйтүлүшү мүмкүн. Репликация фактору 5 жана синхрондоштуруудагы репликалардын минималдуу саны min.insync.replicas=3 билдирүү жоготуу өтө сейрек учурайт. Эгерде сиздин инфраструктураңыз бул репликация катышын жана ашыкчалык деңгээлин колдоого алса, анда сиз бул параметрди тандай аласыз.

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

RabbitMQнын чоң кезектерге болгон алсыздыгына каршы бир антидот - аларды көптөгөн майда кезектерге бөлүү. Эгер сиз бүткүл кезекти толук иреттөөнү талап кылбасаңыз, бирок тиешелүү билдирүүлөрдү гана (мисалы, белгилүү бир кардардан келген билдирүүлөр) же эч нерсеге заказ бербесеңиз, анда бул параметр алгылыктуу: менин долбоорумду караңыз Rebalancer кезекти бөлүү (долбоор али баштапкы этапта).

Акырында, RabbitMQ менен Kafkaнын кластерлөө жана репликациялоо механизмдериндеги бир катар мүчүлүштүктөр жөнүндө унутпаңыз. Убакыттын өтүшү менен системалар жетилген жана туруктуу болуп калды, бирок эч кандай билдирүү жоготуудан 100% коопсуз болбойт! Мындан тышкары, маалымат борборлорунда ири көлөмдөгү кырсыктар!

Эгер мен бир нерсени өткөрүп жиберсем, ката кетирсем же кандайдыр бир пунктка макул болбосоңуз, комментарий жазыңыз же мага кайрылыңыз.

Менден көп сурашат: "Эмнени тандоо керек, Kafka же RabbitMQ?", "Кайсы платформа жакшы?". Чындыгында, бул чындап эле сиздин абалыңызга, учурдагы тажрыйбаңызга ж.б. көз каранды. Мен өз оюмду айтуудан тартынамын, анткени бардык колдонуу учурлары жана мүмкүн болгон чектөөлөр үчүн бир платформаны сунуштоо өтө эле жөнөкөйлөштүрүлбөйт. Мен бул макалалар сериясын сиз өз оюңузду калыптандыруу үчүн жаздым.

Бул тармакта эки система тең лидер экенин айткым келет. Мен бир аз калыс болушум мүмкүн, анткени долбоорлор менен болгон тажрыйбамдан мен кепилденген билдирүү ирети жана ишенимдүүлүк сыяктуу нерселерди баалайм.

Мен бул ишенимдүүлүк жана кепилденген тартип жок башка технологияларды көрүп, анан RabbitMQ менен Кафканы карап, бул эки системанын тең укмуштуудай баалуулугун түшүнөм.

Source: www.habr.com