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

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

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

Біз үйлесімділік пен қолжетімділік спектрдің қарама-қарсы жағында екенін көреміз және оңтайландырудың қай жолын таңдау керек. Жақсы жаңалық - RabbitMQ көмегімен бұл таңдау мүмкін. Сізде тепе-теңдікті жоғарырақ консистенцияға немесе қол жетімділікке қарай жылжыту үшін осындай «ерең» тұтқалар бар.

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

Бір түйінді тұрақтылық примитивтері

Тұрақты кезек/маршруттау

RabbitMQ-те кезектердің екі түрі бар: берік және берік емес. Барлық кезектер Mnesia дерекқорында сақталады. Ұзақ мерзімді кезектер түйінді іске қосу кезінде қайта жарнамаланады және осылайша қайта іске қосу, жүйенің бұзылуы немесе сервердің бұзылуы (деректер сақталғанша) аман қалады. Бұл маршруттауды (алмасу) және кезекті тұрақты деп жариялаған кезде, кезек/маршруттау инфрақұрылымы желіге қайта оралатынын білдіреді.

Түйін қайта іске қосылғанда өзгермелі кезектер мен бағыттау жойылады.

Тұрақты хабарламалар

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

Күріш. 1. Тұрақтылық матрицасы

Кезекті шағылыстыру арқылы кластерлеу

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

Кезекті шағылыстыру:

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

Күріш. 2. Кезекті шағылыстыру

Айналау тиісті саясатпен орнатылады. Онда сіз репликация коэффициентін және тіпті кезек орналасуы керек түйіндерді таңдай аласыз. Мысалдар:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (бір шебер және бір айна)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Жариялаушының растауы

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

Орындау кезегі

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

Күріш. 3. Бірнеше шағылыстырылған кезектер және олардың саясаттары

Брокер 3 төмендейді. Брокер 2-дегі C Queue айнасы шеберлікке көтерілетінін ескеріңіз. Сондай-ақ, 1-брокердегі C кезегі үшін жаңа айна жасалғанын ескеріңіз. RabbitMQ әрқашан саясаттарыңызда көрсетілген репликация факторын сақтауға әрекет жасайды.

Күріш. 4. 3-брокер сәтсіз аяқталды, бұл C кезегінің сәтсіздігін тудырады

Келесі Брокер 1 құлады! Бізде бір ғана брокер қалды. B Queue айнасы шеберлікке көтеріледі.

Сурет. 5

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

Бұл жағдайда 1-брокердің жоғалуы деректер сияқты толық болды, осылайша айналылмаған В кезегі толығымен жоғалды.

Күріш. 6. Брокер 1 қызметке қайтады

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

Күріш. 7. Брокер 3 қызметке қайтады. Барлық негізгі кезектер бір түйінде!

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

Синхрондау

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

Бұл синхрондау автоматты түрде немесе қолмен орындалады және кезек саясаты арқылы басқарылады. Бір мысалды қарастырайық.

Бізде екі шағылыстырылған кезек бар. А кезегі автоматты түрде синхрондалады, ал В кезегі қолмен синхрондалады. Екі кезекте де он хабар бар.

Күріш. 8. Синхрондау режимдері әртүрлі екі кезек

Енді біз Broker 3-тен айырылып жатырмыз.

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

Брокер 3 қызметке қайтады. Кластер жаңа түйіндегі әрбір кезек үшін айна жасайды және жаңа А кезегін мастермен автоматты түрде үндестіреді. Дегенмен, жаңа В кезегінің айнасы бос қалады. Осылайша, бізде А кезегінде толық резерв және бар B кезегі хабарлары үшін тек бір айна болады.

Күріш. 10. А кезегінің жаңа айнасы бар хабарларды қабылдайды, бірақ В кезегінің жаңа айнасы қабылдамайды.

Екі кезекте тағы он хабарлама келеді. Содан кейін 2-брокер бұзылады және А кезегі Брокер 1-дегі ең ескі айнаға оралады. Ол сәтсіз болғанда деректер жоғалмайды. В кезегінде шеберде жиырма хабар және айнада тек он хабар бар, себебі бұл кезек ешқашан бастапқы он хабарды қайталамайды.

Күріш. 11. A кезегі хабарларды жоғалтпай 1-брокерге оралады

Екі кезекте тағы он хабарлама келеді. Енді Broker 1 бұзылды. A кезегі хабарларды жоғалтпай айнаға оңай ауысады. Дегенмен, В кезегінде проблемалар бар. Осы кезде біз қол жетімділікті немесе тұрақтылықты оңтайландыра аламыз.

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

Күріш. 12. А кезегі хабарларды жоғалтпай 3-брокерге қайтарылады. В кезегі он хабар жоғалып, 3-брокерге оралады

Біз де орната аламыз ha-promote-on-failure мағынаға when-synced. Бұл жағдайда айнаға оралудың орнына кезек 1-Брокер деректерімен онлайн режиміне оралғанша күтеді. Ол қайтарылғаннан кейін негізгі кезек деректер жоғалтпай 1-брокерге қайта оралады. Деректердің қауіпсіздігі үшін қол жетімділік құрбан болады. Бірақ бұл қауіпті режим, ол тіпті деректердің толық жоғалуына әкелуі мүмкін, біз оны жақын арада қарастырамыз.

Күріш. 13. 1-брокерді жоғалтқаннан кейін В кезегі қолжетімсіз болып қалады

Сіз: «Автоматты синхрондауды ешқашан пайдаланбаған дұрыс па?» Деп сұрауыңыз мүмкін. Жауап: синхрондау блоктау операциясы болып табылады. Синхрондау кезінде негізгі кезек оқу немесе жазу әрекеттерін орындай алмайды!

Бір мысалды қарастырайық. Қазір бізде өте ұзын кезек бар. Олар мұндай мөлшерге қалай жетеді? Бірнеше себептер бойынша:

• Кезектер белсенді қолданылмайды
• Бұл жоғары жылдамдықтағы кезек, дәл қазір тұтынушылар баяу
• Бұл жоғары жылдамдықтағы кезек, ақаулық орын алып, тұтынушылар қуып жетуде

Күріш. 14. Синхрондау режимдері әртүрлі екі үлкен кезек

Енді Broker 3 құлады.

Күріш. 15. Брокер 3 құлап, әр кезекте бір шебер мен айна қалдырады

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

Дегенмен, В кезегі бүкіл кезең бойы қолжетімді болып қалады. Ол қолжетімділік үшін кейбір артықшылықты құрбан етті.

Күріш. 16. Синхрондау кезінде кезек қолжетімсіз болып қалады

Екі сағаттан кейін A кезегі де қолжетімді болады және оқу мен жазуды қайта қабылдай бастайды.

Жаңартулар

Синхрондау кезіндегі бұл блоктау әрекеті өте үлкен кезектер кластерлерді жаңартуды қиындатады. Белгілі бір сәтте негізгі түйінді қайта іске қосу қажет, бұл сервер жаңартылып жатқанда айнаға ауысуды немесе кезекті өшіруді білдіреді. Егер біз ауысуды таңдасақ, айналар синхрондалмаған жағдайда хабарларды жоғалтамыз. Әдепкі бойынша, брокердің үзілуі кезінде, синхрондалмаған айнаға ауыстыру орындалмайды. Бұл дегеніміз, брокер қайтып келген бойда біз ешқандай хабарламаны жоғалтпаймыз, жалғыз зиян қарапайым кезек болды. Брокер ажыратылған кездегі мінез-құлық ережелері саясатпен белгіленеді ha-promote-on-shutdown. Екі мәннің бірін орнатуға болады:

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

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

Қол жетімділік деректер қауіпсіздігін жақсартқанда

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

Мұнда сіз мыналарды ескеруіңіз керек:

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

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

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

Ha-promote-on-failure=when-синхрондалған ақаулар

Идея сәтсіздікке га-ілгерілету= синхрондалған кезде біз синхрондалмаған айнаға ауысуға жол бермейміз және осылайша деректердің жоғалуына жол бермейміз. Кезек оқылмайды немесе жазылмайды. Оның орнына, біз бұзылған брокерді деректерін жоғалтпай, негізгі ретінде жұмысын жалғастыра алатындай деректерімен қалпына келтіруге тырысамыз.

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

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

Сондықтан, қолмен синхрондау (және синхрондау сәтсіздігі) комбинациясы ha-promote-on-failure=when-synced, менің ойымша, өте қауіпті. Құжаттар бұл опция деректер қауіпсіздігі үшін бар екенін айтады, бірақ бұл екі жақты пышақ.

Шебер теңдестіру

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

Шеберлерді қайта теңестіру екі себепке байланысты проблемалы болуы мүмкін:

• Қайта теңестіруді орындау үшін жақсы құралдар жоқ
• Кезекті синхрондау

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

Негізгі кезекті HA саясаты арқылы жылжытудың тағы бір айласы бар. Нұсқаулықта айтылған сценарий Осыған. Ол келесідей жұмыс істейді:

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

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

Енді RabbitMQ кластерлерінің желі бөлімдерімен қалай жұмыс істейтінін көрейік.

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

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

RabbitMQ көмегімен бізде екі негізгі нұсқа бар:

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

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

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

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

RabbitMQ әртүрлі режимдері қол жетімділікті немесе тұрақтылықты қамтамасыз етеді.

Елемеу режимі (әдепкі)

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

Күріш. 18. Үш баспагер үш брокермен байланысты. Ішкі кластер барлық сұрауларды 2-брокердегі негізгі кезекке бағыттайды.

Енді біз Брокер 3-тен айырылып жатырмыз. Ол басқа брокерлердің құлап кеткенін көріп, шеберге айнасын ұсынады. Осылайша логикалық бөліну пайда болады.

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

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

Күріш. 20. Әкімші 3-брокерді өшіреді.

Күріш. 21. Әкімші 3-брокерді іске қосады және ол кластерге қосылып, онда қалған барлық хабарларды жоғалтады.

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

Автоматты қалпына келтіру режимі

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

Азшылық режимін кідірту

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

Күріш. 22. Үш баспагер үш брокермен байланысты. Ішкі кластер барлық сұрауларды 2-брокердегі негізгі кезекке бағыттайды.

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

Күріш. 23. 3-брокер кідіртеді, барлық клиенттерді ажыратады және қосылым сұрауларын қабылдамайды.

Қосылым қалпына келтірілгеннен кейін ол кластерге оралады.

Негізгі кезек Broker 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

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