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

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

Бул түшүнүктөр система иштебей калганда өзүн кандай алып барарын сүрөттөйт. Тармакка туташуунун бузулушу, сервердин иштебей калышы, катуу дисктин бузулушу, таштанды чогултуунун, пакеттин жоголушу же тармак туташуусу жайлоосунан улам сервердин убактылуу жеткиликсиздиги. Мунун баары маалыматтарды жоготууга же чыр-чатакка алып келиши мүмкүн. Көрсө, бардык мүчүлүштүктөр сценарийлери үчүн толугу менен шайкеш (маалыматтар жоголбогон, маалыматтар айырмаланбайт) жана жеткиликтүү (окууларды жана жазууларды кабыл ала турган) системаны түзүү дээрлик мүмкүн эмес экен.

Биз ырааттуулук жана жеткиликтүүлүк спектрдин карама-каршы жагында экенин көрөбүз жана сиз оптималдаштыруунун кайсы жолун тандашыңыз керек. Жакшы кабар - RabbitMQ менен бул тандоо мүмкүн. Сизде тең салмактуулукту чоңураак ырааттуулукка же чоңураак жеткиликтүүлүккө буруу үчүн ушундай "нерди" рычагдар бар.

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

Single Node Resilience Primitives

Туруктуу кезек/багыттоо

RabbitMQда кезектердин эки түрү бар: бышык жана туруктуу эмес. Бардык кезектер Mnesia маалымат базасында сакталат. Узак мөөнөттүү кезектер түйүн ишке киргенде кайра жарнамаланат жана ошентип кайра күйгүзүүлөрдөн, системанын бузулушунан же сервердин бузулушунан (маалыматтар сакталып турганда) аман калат. Бул сиз маршрутизацияны (алмашуу) жана кезекти туруктуу деп жарыяласаңыз, кезек/маршруттук инфраструктура кайра онлайнга келет дегенди билдирет.

Түйүн кайра иштетилгенде туруксуз кезектер жана маршрутизация алынып салынат.

Туруктуу билдирүүлөр

Кезек туруктуу болгондуктан, анын бардык билдирүүлөрү түйүн кайра иштетилгенде аман калат дегенди билдирбейт. Жарыялоочу тарабынан коюлган билдирүүлөр гана туруктуу (туруктуу). Туруктуу билдирүүлөр брокерге кошумча жүктү жаратат, бирок билдирүү жоготууга жол берилбесе, анда башка вариант жок.

Райс. 1. Туруктуулук матрицасы

Кезекти чагылдыруу менен кластерлөө

Брокерди жоготуудан аман калуу үчүн бизге ашыкча керек. Биз бир нече RabbitMQ түйүндөрүн кластерге бириктирип, андан кийин бир нече түйүндөрдүн ортосундагы кезектерди репликациялоо менен кошумча ашыкчаларды кошо алабыз. Ошентип, бир түйүн иштебей калса, биз маалыматтарды жоготпойбуз жана жеткиликтүү бойдон кала беребиз.

Кезекти чагылдыруу:

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

Райс. 2. Кезекти чагылдыруу

Күзгүзүү тиешелүү саясат менен белгиленет. Анда сиз репликация коэффициентин жана ал тургай кезекте турган түйүндөрдү тандай аласыз. Мисалдар:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (бир мастер жана бир күзгү)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Жарыялоочунун ырастоосу

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

Иштен чыгуу кезеги

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

Райс. 3. Бир нече чагылдырылган кезектер жана алардын саясаттары

Брокер 3 төмөндөйт. Брокер 2деги C Queue күзгүсү чеберчиликке көтөрүлүп жатканын эске алыңыз. Брокер 1деги C кезеги үчүн жаңы күзгү түзүлгөнүн да эске алыңыз. RabbitMQ ар дайым саясаттарыңызда көрсөтүлгөн репликация факторун сактоого аракет кылат.

Райс. 4. Брокер 3 иштебей калып, C кезеги иштебей калат

Кийинки Брокер 1 кулады! Бизде бир гана брокер калды. Queue B күзгүсү устаттыкка көтөрүлөт.

Сүрөт. 5

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

Бул учурда, Брокердин 1 жоголушу толук болгон, ошондой эле маалыматтар, ошондуктан unmirrored Queue B толугу менен жоголгон.

Райс. 6. Брокер 1 кызматка кайтып келет

Брокер 3 кайра онлайнда, андыктан А жана В кезектери HA саясаттарын канааттандыруу үчүн андагы түзүлгөн күзгүлөрдү кайтарып алышат. Бирок азыр бардык негизги кезектер бир түйүндө! Бул идеалдуу эмес, түйүндөр ортосунда бирдей бөлүштүрүү жакшыраак. Тилекке каршы, бул жерде мастерлерди тең салмактоо үчүн көп варианттар жок. Биз бул маселеге кийинчерээк кайрылып келебиз, анткени биринчи кезекте синхрондоштурууну карашыбыз керек.

Райс. 7. Брокер 3 кызматка кайтып келет. Бардык негизги кезектер бир түйүндө!

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

синхрондоштуруу

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

Бул синхрондоштуруу автоматтык түрдө же кол менен аткарылат жана кезек саясаты аркылуу башкарылат. Келгиле, бир мисал карап көрөлү.

Бизде эки күзгү кезеги бар. А кезеги автоматтык түрдө, ал эми Б кезеги кол менен синхрондолот. Эки кезекте тең он билдирүү бар.

Райс. 8. Ар кандай синхрондоштуруу режимдери менен эки кезек

Азыр биз Broker 3ти жоготуп жатабыз.

Райс. 9. Брокер 3 кулады

Брокер 3 кызматка кайтып келет. Кластер жаңы түйүндөгү ар бир кезек үчүн күзгү түзөт жана жаңы А кезекти мастер менен автоматтык түрдө синхрондошот. Бирок, жаңы В кезегинин күзгүсү бош бойдон калууда. Ушундай жол менен биз А кезегинде толук резервге ээ болобуз жана учурдагы B кезеги билдирүүлөрү үчүн бир гана күзгүгө ээ болобуз.

Райс. 10. А кезегинин жаңы күзгүсү учурдагы бардык билдирүүлөрдү кабыл алат, бирок В кезегинин жаңы күзгүсү кабыл албайт.

Эки кезекте дагы он билдирүү келет. Брокер 2 бузулуп, кезек А брокер 1деги эң эски күзгүгө кайтып келет. Ал иштебей калганда маалымат жоголбойт. В кезегинде кожоюнда жыйырма билдирүү жана күзгүдө он гана билдирүү бар, анткени бул кезек эч качан баштапкы он билдирүүнү кайталабайт.

Райс. 11. Кезеги А билдирүүлөрдү жоготпостон 1-брокерге кайтып келет

Эки кезекте дагы он билдирүү келет. Эми Брокер 1 бузулду. Кезеги А билдирүүлөрдү жоготпостон күзгүгө оңой которулат. Бирок, В кезеги көйгөйлөрдү жаратууда. Бул учурда биз же жеткиликтүүлүгүн же ырааттуулугун оптималдаштыруу болот.

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

Райс. 12. А кезеги билдирүүлөрдү жоготпостон 3-брокерге кайтарылат. В кезеги жоголгон он билдирүү менен 3-брокерге кайтып келет

Биз да орното алабыз ha-promote-on-failure мааниге when-synced. Бул учурда, күзгүгө кайтып баруунун ордуна, кезек Брокер 1 маалыматтары менен онлайн режимине кайтканга чейин күтөт. Ал кайтып келгенден кийин, негизги кезек Брокер 1ге эч кандай маалымат жоготуусуз кайтып келет. Маалымат коопсуздугу үчүн жеткиликтүүлүк курмандыкка чалынат. Бирок бул кооптуу режим, ал тургай, биз жакын арада карап чыга турган маалыматтардын толук жоголушуна алып келиши мүмкүн.

Райс. 13. Брокер 1 жоголгондон кийин В кезеги жеткиликсиз бойдон калууда

Сиз: "Автоматтык синхрондоштурууну эч качан колдонбогон жакшыбы?" Жооп синхрондоштуруу бөгөттөө операциясы болуп саналат. Синхрондоштуруу учурунда негизги кезек эч кандай окуу же жазуу операцияларын аткара албайт!

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

• Кезектер активдуу пайдаланылбайт
• Бул жогорку ылдамдыктагы кезектер, азыр керектөөчүлөр жай
• Бул жогорку ылдамдыктагы кезектер, мүчүлүштүктөр болуп, керектөөчүлөр жетип жатышат

Райс. 14. Ар кандай синхрондоштуруу режимдери бар эки чоң кезек

Азыр Broker 3 кулады.

Райс. 15. Брокер 3 жыгылып, ар бир кезекте бир кожоюн жана күзгү калтырат

Брокер 3 кайра онлайнга келип, жаңы күзгүлөр түзүлөт. Негизги кезек А учурдагы билдирүүлөрдү жаңы күзгүгө кайталай баштайт жана бул убакыттын ичинде Кезек жеткиликсиз. Дайындарды кайталоо үчүн эки саат талап кылынат, натыйжада бул кезекте эки саат иштебей калат!

Бирок, В кезеги бүткүл мезгил бою жеткиликтүү бойдон калууда. Жеткиликтүүлүк үчүн ал бир аз ашыкчалыкты курман кылды.

Райс. 16. Синхрондоштуруу учурунда кезек жеткиликсиз бойдон калууда

Эки сааттан кийин А кезек да жеткиликтүү болуп, окууларды жана жазууларды кайра кабыл ала баштайт.

ёркъндётъъ

Бул синхрондоштуруу учурунда бөгөттөө жүрүм-туруму өтө чоң кезектер менен кластерлерди жаңыртууну кыйындатат. Кайсы бир учурда, башкы түйүн кайра иштетилиши керек, бул сервер жаңыланып жатканда күзгүгө өтүүнү же кезекти өчүрүүнү билдирет. Эгер биз өтүүнү тандасак, күзгүлөр шайкештирилбесе, биз кабарларды жоготуп алабыз. Демейки боюнча, брокердин үзгүлтүккө учурашы учурунда, синхрондоштурулган күзгүгө алмаштырылбайт. Бул брокер кайтып келээри менен, биз эч кандай билдирүүлөрдү жоготпойбуз, бир гана зыян жөнөкөй кезек болчу. Брокер ажыратылганда жүрүм-турум эрежелери саясат тарабынан белгиленет ha-promote-on-shutdown. Сиз эки маанинин бирин орното аласыз:

• always= синхрондолбогон күзгүлөргө өтүү иштетилди
• when-synced= синхрондуу күзгүгө гана өтүү, антпесе кезек окулбай жана жазылбай калат. Кезек брокер кайтып келери менен кызматка кайтат

Кандайдыр бир жол менен, чоң кезек менен сиз маалыматтын жоголушу менен жеткиликсиздигинин ортосунда тандоого туура келет.

Качан жеткиликтүүлүк берилиштердин коопсуздугун жакшыртат

Чечим кабыл алуудан мурун дагы бир татаалдык бар. Автоматтык синхрондоштуруу ашыкча болуу үчүн жакшыраак болсо да, ал маалымат коопсуздугуна кандай таасир этет? Албетте, жакшыраак резервдик менен, RabbitMQ учурдагы билдирүүлөрдү жоготуу ыктымалдыгы азыраак, бирок басып чыгаруучулардын жаңы билдирүүлөрү жөнүндө эмне айтууга болот?

Бул жерде сиз төмөнкүлөрдү эске алуу керек:

• Жарыялоочу жөн гана катаны кайтарып, жогорудагы кызмат же колдонуучу кийинчерээк кайра аракет кыла алабы?
• Жарыялоочу кийинчерээк кайра аракет кылуу үчүн билдирүүнү жергиликтүү же маалымат базасында сактай алабы?

Эгерде жарыялоочу билдирүүнү гана жокко чыгара алса, анда чындыгында, жеткиликтүүлүктү жакшыртуу маалымат коопсуздугун да жакшыртат.

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

Ha-promote-on-failure=качан-синхрондоштуруу менен көйгөйлөр

ой ийгиликсиздикке га көмөктөшөт= качан-синхрондоштуруу бул биз синхрондоштурулган күзгүгө өтүүнүн алдын алуу жана ошону менен маалыматтардын жоголушун алдын алуу. Кезек окулбай же жазылышы мүмкүн бойдон калууда. Анын ордуна, биз кыйроого учураган брокерди дайындары бузулбастан калыбына келтирүүгө аракет кылабыз.

Бирок (жана бул чоң, бирок) брокер өз маалыматтарын жоготкон болсо, анда бизде чоң көйгөй бар: кезек жоголду! Бардык маалыматтар жок! Көбүнчө негизги кезекке жеткен күзгүңүз болсо да, ал күзгүлөр да жок кылынат.

Ошол эле аталыштагы түйүндү кайра кошуу үчүн, биз кластерге жоголгон түйүндү унутууну айтабыз (буйрук менен rabbitmqctl leave_cluster_node) жана ошол эле хост аты менен жаңы брокерди баштаңыз. Кластер жоголгон түйүндү эстегенде, эски кезекти жана синхрондоштурулган күзгүлөрдү эстейт. Кластерге жетим түйүн унуту керек десе, ал кезек да унутулуп калат. Эми аны кайра жарыя кылышыбыз керек. Бизде маалыматтардын жарым-жартылай топтому бар күзгүлөр болгонуна карабастан, биз бардык маалыматтарды жоготтук. Синхронизацияланбаган күзгүгө өтсө жакшы болмок!

Ошондуктан, кол менен синхрондоштуруу (жана синхрондоштуруу үчүн аткарбоо) менен айкалышта ha-promote-on-failure=when-synced, менин оюмча, абдан кооптуу. Документтердин айтымында, бул параметр маалымат коопсуздугу үчүн бар, бирок бул эки миздүү бычак.

Мастер кайра баланстоо

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

Мастерлерди тең салмактоо эки себептен улам көйгөйлүү болушу мүмкүн:

• Калыбына келтирүү үчүн жакшы куралдар жок
• Кезекти синхрондоштуруу

Калыбына келтирүү үчүн үчүнчү тарап бар плагин, бул расмий түрдө колдоого алынбайт. RabbitMQ колдонмосунда үчүнчү тараптын плагиндери жөнүндө мындай деди:: "Плагин кээ бир кошумча конфигурация жана отчеттук куралдар менен камсыз кылат, бирок RabbitMQ командасы тарабынан колдоого алынбайт же текшерилбейт. Өзүңүздүн тобокелиңиз менен колдонуңуз."

HA саясаттары аркылуу негизги кезекти жылдыруунун дагы бир амалы бар. Колдонмодо айтылат скрипт бул үчүн. Ал мындай иштейт:

• Учурдагы HA саясатына караганда артыкчылыктуу убактылуу саясаттын жардамы менен бардык күзгүлөрдү алып салат.
• Түйүн режимин колдонуу үчүн HA убактылуу саясатын өзгөртүп, башкы кезек өткөрүлө турган түйүндү белгилейт.
• Түртүү миграциясы үчүн кезекти синхрондоштуруу.
• Көчүрүү аяктагандан кийин, убактылуу саясат жок кылынат. Алгачкы HA саясаты күчүнө кирет жана күзгүлөрдүн керектүү саны түзүлөт.

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

Эми RabbitMQ кластерлери тармак бөлүмдөрү менен кантип иштээрин карап көрөлү.

байланышты жоготуу

Бөлүштүрүлгөн системанын түйүндөрү тармактык шилтемелер аркылуу туташтырылган жана тармактык шилтемелер ажыратылышы мүмкүн жана ажыратылат. Өчүрүүлөрдүн жыштыгы жергиликтүү инфраструктурага же тандалган булуттун ишенимдүүлүгүнө жараша болот. Кандай болгон күндө да, бөлүштүрүлгөн системалар алар менен күрөшүүгө жөндөмдүү болушу керек. Дагы бир жолу бизде жеткиликтүүлүк менен ырааттуулуктун ортосунда тандоо бар жана дагы бир жакшы кабар - RabbitMQ эки вариантты тең камсыздайт (бир эле учурда эмес).

RabbitMQ менен бизде эки негизги вариант бар:

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

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

Райс. 17. Негизги кезек жана эки күзгү, ар бири өзүнчө түйүндөр. Андан кийин тармак бузулуп, бир күзгү ажырап калат. Бөлүнгөн түйүн калган экөөнүн кулап калганын көрүп, күзгүлөрүн кожоюнуна жылдырат. Азыр бизде эки негизги кезек бар, алар жазыла турган жана окула турган.

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

RabbitMQ ар кандай режимдери же жеткиликтүүлүгүн же ырааттуулугун камсыз кылат.

Эңкейбоо режими (демейки)

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

Райс. 18. Үч жарыялоочу үч брокер менен байланышкан. Ички кластер бардык суроо-талаптарды Брокер 2деги негизги кезекке багыттайт.

Азыр биз Брокер 3 жоготуп жатабыз. Ал башка брокерлер түшүп калганын көрүп, анын күзгүсүн кожоюнуна жылдырат. Бул логикалык бөлүнүү пайда болот.

Райс. 19. Логикалык бөлүнүү (бөлүнгөн мээ). Жазуулар эки негизги кезекке түшүп, эки нускада айырмаланат.

Байланыш калыбына келтирилди, бирок логикалык бөлүнүү сакталат. Администратор утулган тарапты кол менен тандашы керек. Төмөнкү учурда, администратор Broker 3ти кайра жүктөйт. Ал өткөрүп бере албаган бардык билдирүүлөр жоголот.

Райс. 20. Администратор 3-брокерди өчүрөт.

Райс. 21. Администратор 3-брокерди ишке киргизет жана ал кластерге кошулуп, анда калган бардык билдирүүлөрдү жоготот.

Байланыш үзүлгөндө жана аны калыбына келтиргенден кийин, кластер жана бул кезек окуу жана жазуу үчүн жеткиликтүү болгон.

Авто айыктыруу режими

Кластер автоматтык түрдө ажырап, туташууну калыбына келтиргенден кийин утулган тарапты тандап алгандан башка, Игнор режимине окшош иштейт. Жоголгон тарап кластерге бош кайтып келет, ал эми кезек ошол тарапка гана жөнөтүлгөн бардык билдирүүлөрдү жоготот.

Азчылык режимин тындыруу

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

Райс. 22. Үч жарыялоочу үч брокер менен байланышкан. Ички кластер бардык суроо-талаптарды Брокер 2деги негизги кезекке багыттайт.

Андан кийин 1 жана 2-брокерлер Брокер 3төн бөлүнүшөт. Алардын күзгүсүн мастерге көтөрүүнүн ордуна, Брокер 3 убактылуу токтотуп, жеткиликсиз болуп калат.

Райс. 23. Брокер 3 тындырат, бардык кардарларды ажыратат жана байланыш сурамдарын четке кагат.

Байланыш калыбына келтирилгенден кийин, ал кластерге кайтып келет.

Негизги кезек Брокер 3-де турган дагы бир мисалды карап көрөлү.

Райс. 24. Брокер 3 боюнча негизги кезек.

Анан ошол эле байланышты жоготуу пайда болот. Брокер 3 тыным кылат, анткени ал кичинекей тарапта. Башка жагынан алганда, түйүндөр Брокер 3 кулап калганын көрүшөт, ошондуктан 1 жана 2-брокерлердин эски күзгүсү мастерге көтөрүлөт.

Райс. 25. Брокер 2 жок болсо, 3-брокерге өтүү.

Байланыш калыбына келтирилгенде, Брокер 3 кластерге кошулат.

Райс. 26. Кластер кадимки режимге кайтып келди.

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

Жеткиликтүүлүгүн камсыз кылуу үчүн, кардарлардын хостко ийгиликтүү туташуусун камсыз кылуу маанилүү. Келгиле, биздин варианттарды карап көрөлү.

Кардар байланышын камсыз кылуу

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

Биздин варианттар:

• Кластерге жөн гана түйүндөр аркылуу айлануучу жүк балансы аркылуу кирүүгө болот жана кардарлар ийгиликтүү болгонго чейин кайра туташуу аракетин көрүшөт. Эгерде түйүн иштебей калса же убактылуу токтотулса, анда ал түйүнгө туташуу аракети ишке ашпай калат, бирок кийинки аракеттер башка серверлерге өтөт (айлануу режиминде). Бул кыска мөөнөттүү байланышты жоготууга же бузулган серверге ылайыктуу, ал тез калыбына келтирилет.
• Жүк баланстоочу аркылуу кластерге кириңиз жана токтотулган/ишке ашпаган түйүндөр аныкталгандан кийин тизмеден алып салыңыз. Эгер биз муну тез жасасак жана кардарлар туташууну кайра аракет кыла алышса, анда биз туруктуу жеткиликтүүлүккө жетишебиз.
• Ар бир кардарга бардык түйүндөрдүн тизмесин бериңиз жана кардар туташуу учурунда алардын бирин туш келди тандайт. Эгер туташууга аракет кылып жатканда ката алса, ал кошулганга чейин тизмедеги кийинки түйүнгө өтөт.
• DNS аркылуу ишке ашпай калган/токтолуп калган түйүндөн трафикти алып салыңыз. Бул кичинекей TTL колдонуу менен жүзөгө ашырылат.

табылгалары

RabbitMQ кластеринде анын артыкчылыктары жана кемчиликтери бар. Эң олуттуу кемчиликтери болуп төмөнкүлөр саналат:

• кластерге кошулганда түйүндөр өз маалыматтарын жокко чыгарышат;
• синхрондоштурууну бөгөттөө кезектин жеткиликсиз болуп калышына алып келет.

Бардык татаал чечимдер ушул эки архитектуралык өзгөчөлүктөн келип чыгат. Эгерде RabbitMQ кластер кайра кошулганда маалыматтарды сактай алса, анда синхрондоштуруу тезирээк болмок. Эгер ал бөгөттөлбөгөн синхрондоштурууга жөндөмдүү болсо, чоң кезектерди жакшыраак колдоого алмак. Бул эки маселени чечүү RabbitMQнын катага чыдамдуу жана жеткиликтүү билдирүү технологиясы катары иштешин бир топ жакшыртмак. Төмөнкү кырдаалдарда кластерлөө менен RabbitMQ сунуш кылуудан тартынбайм:

• Ишенимсиз тармак.
• Ишенимсиз сактагыч.
• Абдан узун кезектер.

Жогорку жеткиликтүүлүк орнотууларына келгенде, төмөнкүлөрдү эске алыңыз:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (же autoheal)
• туруктуу билдирүүлөр
• кээ бир түйүн иштебей калганда кардарлардын активдүү түйүнгө туташуусун камсыз кылуу

Ыкчамдуулук (маалымат коопсуздугу) үчүн төмөнкү орнотууларды карап көрүңүз:

• Жарыялоочу тастыктайт жана керектөөчү тарабынан кол менен тастыктайт
• ha-promote-on-failure=when-synced, эгерде жарыялоочулар кийинчерээк кайра аракет кыла алышат жана сизде абдан ишенимдүү сактагыч болсо! Болбосо кой =always.
• ha-sync-mode=automatic (бирок чоң жигердүү эмес кезектер үчүн кол режими талап кылынышы мүмкүн; ошондой эле жеткиликсиздик билдирүүлөрдүн жоголушуна себеп болобу)
• Азчылык режимин тындыруу
• туруктуу билдирүүлөр

Биз каталарга чыдамдуулук жана жогорку жеткиликтүүлүк маселелерин азырынча камтый элекпиз; мисалы, административдик процедураларды кантип коопсуз аткаруу керек (мисалы, жаңыртуулар). Биз ошондой эле федерация жана Shovel плагини жөнүндө сүйлөшүшүбүз керек.

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

Менин да караңыз кызмат, бул жерде мен бул макалада сүрөттөлгөн билдирүүлөрдү жоготуу сценарийлерин сынап көрүү үчүн Docker жана Blockade аркылуу RabbitMQ кластерин бузуп жатам.

Сериядагы мурунку макалалар:
№1 - habr.com/ru/company/itsumma/blog/416629
№2 - habr.com/ru/company/itsumma/blog/418389
№3 - habr.com/ru/company/itsumma/blog/437446

Source: www.habr.com