Səhvlərə dözümlülük və yüksək əlçatanlıq böyük mövzulardır, ona görə də biz RabbitMQ və Kafkaya ayrıca məqalələr həsr edəcəyik. Bu məqalə RabbitMQ haqqında, növbəti məqalə isə Kafka ilə RabbitMQ haqqındadır. Məqalə uzundur, ona görə də rahat olun.

Gəlin səhvlərə dözümlülük, ardıcıllıq və yüksək əlçatanlıq (HA) strategiyalarına və hər bir strategiyanın etməli olduğu güzəştlərə nəzər salaq. RabbitMQ bir çox qovşaqda işləyə bilər - və sonra paylanmış sistem kimi təsnif edilir. Paylanmış sistemlərə gəldikdə, biz tez-tez ardıcıllıq və mövcudluq haqqında danışırıq.

Bu anlayışlar sistemin uğursuz olduqda necə davranacağını təsvir edir. Şəbəkə bağlantısı nasazlığı, server nasazlığı, sabit disk nasazlığı, zibil toplanması səbəbindən serverin müvəqqəti əlçatmazlığı, paket itkisi və ya şəbəkə bağlantısının yavaşlaması. Bütün bunlar məlumat itkisinə və ya münaqişələrə səbəb ola bilər. Məlum oldu ki, bütün uğursuzluq ssenariləri üçün həm tam ardıcıl (məlumat itkisi, nə məlumat uyğunsuzluğu), həm də mövcud (oxumaq və yazmaları qəbul edəcək) sistemi qurmaq demək olar ki, mümkün deyil.

Ardıcıllığın və mövcudluğun spektrin müxtəlif uclarında olduğunu görəcəyik və siz optimallaşdırmağın hansı yolunu seçməlisiniz. Yaxşı xəbər budur ki, RabbitMQ ilə bu seçim mümkündür. Balansınızı daha tutarlılığa və ya daha çox əlçatanlığa doğru dəyişmək üçün bir növ "nerdish" rıçaqlarınız var.

Hansı konfiqurasiyaların qəbul edilmiş yazılara görə məlumat itkisinə səbəb olduğuna xüsusi diqqət yetirəcəyik. Nəşriyyatçılar, brokerlər və istehlakçılar arasında məsuliyyət zənciri var. Mesaj brokerə ötürüldükdən sonra mesajı itirməmək onun işidir. Broker naşirə mesajı qəbul etdikdə, onun itəcəyini gözləmirik. Ancaq bunun həqiqətən brokerinizin və naşirinizin konfiqurasiyasından asılı olaraq baş verə biləcəyini görəcəyik.

Tək Node Dayanıqlılıq Primitivləri

Davamlı növbələr/marşrutlaşdırma

RabbitMQ-da iki növ növbə var: davamlı/sabit (davamlı) və qeyri-sabit (qeyri-davamlı). Bütün növbələr Mnesia verilənlər bazasında saxlanılır. Dözümlü növbələr qovşağın işə salınması zamanı yenidən elan edilir və beləliklə, yenidən başladın, sistem qəzası və ya server qəzası (məlumatlar davam etdikcə) sağ qalır. Bu o deməkdir ki, siz marşrutlaşdırma (mübadilə) və növbənin davamlı olduğunu bəyan etdiyiniz müddətdə növbə/marşrutlaşdırma infrastrukturu yenidən onlayn olacaq.

Düyün yenidən işə salındıqda uçucu növbələr və marşrutlaşdırma silinir.

Davamlı mesajlar

Növbənin davamlı olması onun bütün mesajlarının qovşağın yenidən başlamasından sağ qalacağı anlamına gəlmir. Yalnız naşir tərəfindən təyin edilmiş mesajlar möhkəm (davamlı). Davamlı mesajlar brokerə əlavə yük qoyur, lakin mesaj itkisi qəbuledilməzdirsə, başqa seçim yoxdur.

düyü. 1. Sabitlik matrisi

Növbənin əks olunması ilə klasterləşdirmə

Bir broker itkisindən sağ çıxmaq üçün bizə ehtiyat lazımdır. Biz çoxlu RabbitMQ qovşaqlarını qruplaşdıra və sonra növbələri çoxsaylı qovşaqlarda təkrarlamaqla əlavə ehtiyat əlavə edə bilərik. Beləliklə, bir node aşağı düşərsə, məlumatları itirmirik və mövcud qalırıq.

Növbənin əks olunması:

• bütün yazmaq və oxumaq əmrlərini qəbul edən bir əsas növbə (master).
• əsas növbədən bütün mesajları və metaməlumatları qəbul edən bir və ya bir neçə güzgü. Bu güzgülər miqyaslaşdırmaq üçün deyil, sırf artıqlıq üçün mövcuddur.

düyü. 2. Növbənin əks olunması

Yansıtma müvafiq siyasətlə müəyyən edilir. Bunun içərisində replikasiya faktorunu və hətta növbənin yerləşdirilməli olduğu qovşaqları seçə bilərsiniz. Nümunələr:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (bir usta və bir güzgü)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Nəşriyyat təsdiqi

Ardıcıl yazıya nail olmaq üçün Publisher Confirms tələb olunur. Onlar olmadan mesajları itirmək şansı var. Mesaj diskə yazıldıqdan sonra naşirə bildiriş göndərilir. RabbitMQ mesajları diskə qəbzlə deyil, dövri olaraq, bir neçə yüz millisaniyəlik ərazidə yazır. Növbə əks olunduqda, bildiriş yalnız bütün güzgülər mesajın surətini diskə yazdıqdan sonra göndərilir. Bu o deməkdir ki, təsdiqləmələrin istifadəsi gecikməni artırır, lakin məlumatların təhlükəsizliyi vacibdirsə, onlar lazımdır.

uğursuzluq növbəsi

Broker bağlandıqda və ya qəzaya uğradıqda, həmin qovşaqdakı bütün növbə liderləri (master) onunla birlikdə düşür. Sonra klaster hər bir ustanın ən köhnə güzgüsünü seçir və onu yeni usta kimi təbliğ edir.

düyü. 3. Çoxsaylı güzgü növbələri və onların siyasətləri

Broker 3 qəzaya uğradı. Qeyd edək ki, Broker 2-də C növbəsinin güzgüsü master səviyyəsinə yüksəldilir. Həmçinin nəzərə alın ki, Broker 1-də C növbəsi üçün yeni güzgü yaradılıb. RabbitMQ həmişə siyasətinizdə göstərilən replikasiya faktorunu saxlamağa çalışır.

düyü. 4. Broker 3 düşür və C növbəsinin sıradan çıxmasına səbəb olur

Növbəti Broker 1 aşağıdır! Yalnız bir brokerimiz qalıb. B növbəsinin güzgüsü ustaya yüksəldilir.

Fig. 5

Biz Broker 1-i geri qaytardıq. Brokerin itməsi və bərpası zamanı verilənlərin nə qədər yaxşı sağ qalmasından asılı olmayaraq, bütün güzgülü növbə mesajları yenidən başladıqda silinir. Nəticələri olacağı üçün bunu qeyd etmək vacibdir. Bu təsirləri tezliklə nəzərdən keçirəcəyik. Beləliklə, Broker 1 indi yenidən klasterin üzvüdür və klaster siyasətlərə əməl etməyə çalışır və buna görə də Broker 1-də güzgülər yaradır.

Bu halda, Broker 1-in itirilməsi, məlumatların itirilməsi kimi tam idi, beləliklə, əks olunmayan B növbəsi tamamilə itirilir.

düyü. 6. Broker 1 xidmətə qayıdır

Broker 3 yenidən onlayndır, buna görə də A və B növbələri HA siyasətlərini təmin etmək üçün güzgülərini geri alır. Ancaq indi bütün əsas növbələr eyni qovşaqdadır! Mükəmməl deyil, qovşaqlar arasında vahid paylanmanın olması daha yaxşıdır. Təəssüf ki, ustaları yenidən balanslaşdırmaq üçün xüsusi seçimlər yoxdur. Bu problemə daha sonra qayıdacağıq, çünki əvvəlcə növbə sinxronizasiyasını nəzərdən keçirməliyik.

düyü. 7. Broker 3 xidmətə qayıdır. Bütün əsas növbələr bir qovşaqda!

Beləliklə, indi güzgülərin artıqlığı və nasazlığa dözümlülüyü necə təmin etdiyi barədə bir fikrə sahib olmalısınız. Bu, bir node nasazlığı halında mövcudluğu təmin edir və məlumat itkisindən qoruyur. Amma biz hələ bitirməmişik, çünki əslində hər şey daha mürəkkəbdir.

Sinxronizasiya

Yeni bir güzgü yaradıldıqda, bütün yeni mesajlar həmişə həmin güzgüyə və digərlərinə təkrarlanacaq. Əsas növbədəki mövcud məlumatlara gəldikdə, biz onu masterin tam surətinə çevrilən yeni güzgüyə təkrarlaya bilərik. Biz həmçinin mövcud mesajları təkrarlamamağı seçə bilərik və yeni mesajların quyruğa daxil olduğu və mövcud mesajların əsas növbənin başını tərk etdiyi vaxtda əsas növbə ilə yeni güzgünün birləşməsinə icazə verə bilərik.

Bu sinxronizasiya avtomatik və ya əl ilə olur və növbə siyasəti ilə idarə olunur. Məsələni nəzərdən keçirək.

İki güzgü növbəmiz var. Növbə A avtomatik, B növbəsi isə əl ilə sinxronlaşdırılır. Hər iki növbə on mesajdan ibarətdir.

düyü. 8. Müxtəlif vaxt rejimləri ilə iki növbə

İndi biz Broker 3-ü itiririk.

düyü. 9. Broker 3 aşağı düşdü

Broker 3 yenidən xidmətdədir. Klaster yeni qovşaqda hər növbə üçün güzgü yaradır və yeni A növbəsini master ilə avtomatik sinxronlaşdırır. Bununla belə, yeni B növbəsinin güzgüsü boş qalır. Beləliklə, bizdə A növbəsinin tam ehtiyatı və B növbəsinin mövcud mesajları üçün yalnız bir güzgü var.

düyü. 10. A növbəsinin yeni güzgüsü bütün mövcud mesajları qəbul edir, lakin B növbəsinin yeni güzgüsü qəbul etmir.

Hər iki növbə daha on mesaj alır. Broker 2 daha sonra aşağı düşür və A Növbəsi Broker 1-də olan ən köhnə güzgüyə qayıdır. O, uğursuz olduqda məlumat itkisi olmur. B növbəsinin ustadda iyirmi, güzgüdə isə yalnız on mesajı var, çünki bu növbə heç vaxt orijinal on mesajı təkrarlamırdı.

düyü. 11. Növbə A mesaj itkisi olmadan Broker 1 tərəfindən geri qaytarılır

Hər iki növbə hər biri daha on mesaj alır. Broker 1 indi çökür. A növbəsi heç bir mesaj itkisi olmadan güzgüyə keçir. Bununla belə, B növbəsində problemlər var. Bu nöqtədə biz ya mövcudluğu, ya da ardıcıllığı optimallaşdıra bilərik.

Əlçatanlığı optimallaşdırmaq istəyiriksə, siyasət uğursuzluqda-təşviq et -də quraşdırılmalıdır həmişə. Bu, defolt dəyərdir, ona görə də siz sadəcə olaraq siyasəti ümumiyyətlə təyin edə bilməzsiniz. Belə bir vəziyyətdə, əslində, sinxronizasiya olunmayan güzgülərdə uğursuzluqlara yol veririk. Bu, mesajların itirilməsinə səbəb olacaq, lakin növbə oxuna bilən və yazıla bilən olaraq qalır.

düyü. 12. A növbəsi mesaj itkisi olmadan Broker 3-ə qaytarılır. B növbəsi on mesajı itirməklə Broker 3-ə qayıdır

Biz də quraşdıra bilərik ha-promote-on-failure mənaya keçir when-synced. Bu halda, növbə güzgüyə qayıtmaq əvəzinə, Broker 1 öz məlumatları ilə onlayn qayıdana qədər gözləyəcək. Qayıdandan sonra əsas növbə məlumat itkisi olmadan Broker 1-ə qayıdır. Məlumat təhlükəsizliyi üçün əlçatanlıq qurban verilir. Lakin bu, hətta qısa zamanda nəzərdən keçirəcəyimiz məlumatların tam itkisinə səbəb ola biləcək riskli bir rejimdir.

düyü. 13. Broker 1-i itirdikdən sonra B növbəsi əlçatmaz olaraq qalır

Siz sual verə bilərsiniz: "Bəlkə heç vaxt avtomatik sinxronizasiyadan istifadə etməmək daha yaxşıdır?". Cavab budur ki, sinxronizasiya bloklama əməliyyatıdır. Sinxronizasiya zamanı əsas növbə heç bir oxuma və ya yazma əməliyyatını yerinə yetirə bilməz!

Məsələni nəzərdən keçirək. İndi çox uzun növbələrimiz var. Onlar necə bu qədər böyüyə bilər? Bir neçə səbəbə görə:

• Növbələr aktiv şəkildə istifadə edilmir
• Bunlar yüksək sürətli növbələrdir və hazırda istehlakçılar yavaş işləyirlər.
• Bunlar yüksək sürətli növbələrdir, nasazlıq yaranıb və istehlakçılar yetişir

düyü. 14. Müxtəlif vaxt rejimləri ilə iki böyük növbə

Broker 3 indi çökür.

düyü. 15. Broker 3 hər növbədə bir usta və güzgü buraxaraq qəzaya uğrayır

Broker 3 yenidən onlayn olur və yeni güzgülər yaradılır. Master Queue A mövcud mesajları yeni güzgüdə təkrarlamağa başlayır və bu müddət ərzində Növbə əlçatan deyil. Məlumatın təkrarlanması iki saat çəkir, nəticədə bu növbə üçün iki saat dayanma vaxtı yaranır!

Bununla belə, B növbəsi bütün dövr ərzində mövcud olaraq qalır. O, əlçatanlıq üçün bəzi ehtiyatları qurban verdi.

düyü. 16. Sinxronizasiya zamanı növbə əlçatmaz olaraq qalır

İki saatdan sonra A növbəsi də əlçatan olur və oxunuşları və yazıları yenidən qəbul etməyə başlaya bilər.

Updates

Sinxronizasiya zamanı bu bloklama davranışı çox böyük növbələri olan klasterləri yeniləməyi çətinləşdirir. Müəyyən bir nöqtədə, master node yenidən işə salınmalıdır, bu da ya güzgüyə getmək və ya server yeniləməsi zamanı növbəni söndürmək deməkdir. Əgər keçidi seçsək, güzgülər sinxronizasiya olunmazsa, mesajları itirəcəyik. Defolt olaraq, brokerin kəsilməsi zamanı sinxronizasiyadan kənar güzgüyə keçid həyata keçirilmir. Bu o deməkdir ki, broker geri qayıdan kimi biz heç bir mesajı itirmirik, yeganə ziyan sadə növbə idi. Brokerin əlaqəsi kəsildikdə davranış qaydaları siyasət tərəfindən müəyyən edilir ha-promote-on-shutdown. Siz iki dəyərdən birini təyin edə bilərsiniz:

• always= Sinxronlaşdırılmamış güzgülərə keçid aktivləşdirildi
• when-synced= Yalnız sinxronlaşdırılmış güzgüyə keçin, əks halda növbə oxunmaz və yazıla bilən olur. Broker qayıdan kimi növbə xidmətə qayıdır

Bu və ya digər şəkildə, böyük növbələrlə məlumat itkisi və əlçatmazlıq arasında seçim etməlisiniz.

Mövcudluq Məlumat Təhlükəsizliyini Təkmilləşdirdikdə

Qərar verməzdən əvvəl nəzərə alınmalı olan daha bir mürəkkəblik var. Avtomatik sinxronizasiya ehtiyat üçün daha yaxşı olsa da, məlumat təhlükəsizliyinə necə təsir edir? Əlbəttə ki, daha yaxşı ehtiyatla, RabbitMQ mövcud mesajları itirmək ehtimalı daha azdır, lakin nəşriyyatlardan gələn yeni mesajlar haqqında nə demək olar?

Burada aşağıdakıları nəzərə almalısınız:

• Naşir sadəcə xəta qaytara və yuxarı xidmət və ya istifadəçiyə daha sonra yenidən cəhd edə bilərmi?
• Naşir sonra yenidən cəhd etmək üçün mesajı yerli və ya verilənlər bazasında saxlaya bilərmi?

Nəşriyyatçı yalnız mesajı ləğv edə bilirsə, əslində əlçatanlığın təkmilləşdirilməsi həm də məlumatların təhlükəsizliyini yaxşılaşdırır.

Beləliklə, tarazlıq axtarmaq lazımdır və qərar konkret vəziyyətdən asılıdır.

Ha-promote-on-failure=when-sinxronizasiya ilə bağlı problemlər

Fikir uğursuzluqda-təşviq et= sinxronizasiya edildikdə odur ki, biz sinxronlaşdırılmamış güzgüyə keçidin qarşısını alırıq və bununla da məlumat itkisinin qarşısını alırıq. Növbə oxunmaz və ya yazıla bilən olaraq qalır. Bunun əvəzinə biz yıxılan brokeri bütöv məlumatlarla geri qaytarmağa çalışırıq ki, o, məlumat itkisi olmadan master kimi davam edə bilsin.

Lakin (və bu böyükdür, lakin) əgər broker məlumatlarını itiribsə, onda bizim böyük problemimiz var: növbə itirildi! Bütün məlumatlar getdi! Əsas növbəyə çatan güzgüləriniz olsa belə, həmin güzgülər də atılır.

Eyni adlı qovşağı yenidən əlavə etmək üçün klasterə yetim qovşağı unutmağı əmr edirik ( rabbitmqctl unutmaq_cluster_node) və eyni host adı ilə yeni broker başlayın. Klaster itirilmiş nodu xatırlayarkən, köhnə növbəni və sinxronizasiya olunmayan güzgüləri xatırlayır. Klasterə itirilmiş nodu unutmaq deyildikdə, bu növbə də unudulur. İndi biz bunu yenidən bəyan etməliyik. Qismən məlumat dəsti ilə güzgülərimiz olsa da, bütün məlumatları itirdik. Sinxronlaşdırılmamış güzgüyə keçmək daha yaxşı olardı!

Buna görə də, manuel sinxronizasiya (və sinxronizasiya edilməməsi) ilə birlikdə ha-promote-on-failure=when-syncedmənim fikrimcə olduqca risklidir. Sənədlər bu seçimin məlumatların təhlükəsizliyi üçün mövcud olduğunu deyir, lakin bu, iki tərəfli bıçaqdır.

Usta yenidən balanslaşdırma

Söz verdiyimiz kimi, bütün ustaların bir və ya bir neçə qovşaqda yığılması probleminə qayıdırıq. Bu, hətta klasterin yuvarlanan yenilənməsi nəticəsində baş verə bilər. Üç qovşaqlı çoxluqda bütün əsas növbələr bir və ya iki qovşaqda toplanacaq.

Ustaların yenidən balanslaşdırılması iki səbəbə görə problemli ola bilər:

• Yenidən balanslaşdırma aparmaq üçün yaxşı alətlər yoxdur
• Növbə sinxronizasiyası

Yenidən balanslaşdırma üçün üçüncü tərəf var plugin, bu, rəsmi olaraq dəstəklənmir. RabbitMQ təlimatında üçüncü tərəf plaginləri ilə bağlı deyilir: "Plugin bəzi əlavə konfiqurasiya və hesabat alətləri təqdim edir, lakin RabbitMQ komandası tərəfindən dəstəklənmir və sınaqdan keçirilmir. Öz riskinizlə istifadə edin."

Əsas növbəni HA siyasətləri vasitəsilə köçürmək üçün başqa bir hiylə var. Təlimat qeyd edir ssenari bunun üçün. Bu belə işləyir:

• Mövcud HA siyasətindən daha yüksək prioritetli müvəqqəti siyasətdən istifadə edərək bütün güzgüləri silir.
• Əsas növbəni köçürmək istədiyiniz qovşağı göstərərək "qovşaqlar" rejimindən istifadə etmək üçün müvəqqəti HA siyasətini dəyişir.
• Məcburi miqrasiya üçün növbəni sinxronlaşdırır.
• Miqrasiya tamamlandıqdan sonra müvəqqəti siyasəti silir. Orijinal HA siyasəti qüvvəyə minir və lazımi sayda güzgü yaradılır.

İşin mənfi tərəfi odur ki, böyük növbələriniz və ya ciddi ehtiyat tələbləriniz varsa, bu yanaşma işləməyə bilər.

İndi gəlin RabbitMQ klasterlərinin şəbəkə bölmələri ilə necə işlədiyinə baxaq.

Bağlantının pozulması

Paylanmış sistemin qovşaqları şəbəkə əlaqələri ilə birləşdirilir və şəbəkə əlaqələri kəsilə bilər və kəsiləcək. Kesintilərin tezliyi yerli infrastrukturdan və ya seçilmiş buludun etibarlılığından asılıdır. İstənilən halda, paylanmış sistemlər onları idarə edə bilməlidir. Yenə əlçatanlıq və ardıcıllıq arasında seçimimiz var və yenə də yaxşı xəbər budur ki, RabbitMQ hər iki variantı təqdim edir (yalnız eyni vaxtda deyil).

RabbitMQ ilə iki əsas seçimimiz var:

• Məntiqi ayrılmağa icazə verin (bölünmüş beyin). Bu, mövcudluğu təmin edir, lakin məlumat itkisinə səbəb ola bilər.
• Məntiqi ayırmanı deaktiv edin. Müştərilərin klasterə necə qoşulmasından asılı olaraq qısamüddətli əlçatanlığın itirilməsi ilə nəticələnə bilər. O, həmçinin iki qovşaqlı çoxluqda tam əlçatmazlığa səbəb ola bilər.

Bəs məntiqi ayrılıq nədir? Bu, şəbəkə əlaqələrinin itirilməsi səbəbindən klasterin ikiyə bölünməsidir. Hər tərəfdə güzgülər ustaya yüksəldilir ki, sonda hər növbədə bir neçə usta var.

düyü. 17. Əsas növbə və iki güzgü, hər biri ayrı bir node. Sonra şəbəkə çatışmazlığı var və bir güzgü ayrılır. Ayrılan düyün digər ikisinin yıxıldığını görür və güzgülərini ustaya doğru irəliləyir. İndi iki əsas növbəmiz var, hər ikisi oxuna bilən və yaza biləndir.

Nəşriyyatçılar hər iki ustaya məlumat göndərsələr, növbənin iki fərqli nüsxəsi olacaq.

RabbitMQ-nun müxtəlif rejimləri ya mövcudluğu, ya da ardıcıllığı təmin edir.

İqnor rejimi (defolt)

Bu rejim əlçatanlığı təmin edir. Bağlantının itirilməsindən sonra məntiqi ayrılma baş verir. Bağlantı bərpa edildikdən sonra administrator hansı bölmənin prioritetləşdirilməsinə qərar verməlidir. Uduzan tərəf yenidən işə salınacaq və həmin tərəfdən bütün yığılmış məlumatlar itiriləcək.

düyü. 18. Üç naşir üç brokerlə əlaqəlidir. Daxili olaraq, klaster bütün sorğuları Broker 2-də əsas növbəyə yönləndirir.

İndi biz Broker 3-ü itiririk. O, digər brokerlərin yıxıldığını görür və güzgüsünü ustaya çatdırır. Məntiqi ayrılma belə baş verir.

düyü. 19. Məntiqi bölmə (parçalanmış beyin). Qeydlər iki əsas növbəyə gedir və iki nüsxə çıxır.

Bağlantı bərpa olunur, lakin məntiqi ayrılma qalır. Administrator uduzan tərəfi əl ilə seçməlidir. Aşağıdakı halda, administrator Broker 3-ü yenidən işə salır. Onun ötürməyə vaxtı olmadığı bütün mesajlar itirilir.

düyü. 20. Administrator Broker 3-ü söndürür.

düyü. 21. Administrator Broker 3-ü işə salır və o, orada qalan bütün mesajları itirərək klasterə qoşulur.

Bağlantının itirilməsi zamanı və bərpa edildikdən sonra klaster və bu növbə oxumaq və yazmaq üçün mövcud idi.

Avtomatik müalicə rejimi

İqnor rejiminə bənzər işləyir, istisna olmaqla, klasterin özü bölünüb yenidən qoşulduqdan sonra avtomatik olaraq itirən tərəfi seçir. Uduzan tərəf boş klasterə qayıdır və növbə yalnız həmin tərəfə göndərilən bütün mesajları itirir.

Kiçik rejimi dayandırın

Məntiqi bölməyə icazə vermək istəmiriksə, onda bizim yeganə seçimimiz klaster bölməsindən sonra kiçik tərəfdə oxumaq və yazmaqdan imtina etməkdir. Broker daha kiçik tərəfdə olduğunu görəndə işi dayandırır, yəni bütün mövcud əlaqələri bağlayır və yeniləri rədd edir. Saniyədə bir dəfə yenidən əlaqəni yoxlayır. Bağlantı bərpa olunan kimi işi bərpa edir və klasterə qoşulur.

düyü. 22. Üç naşir üç brokerlə əlaqəlidir. Daxili olaraq, klaster bütün sorğuları Broker 2-də əsas növbəyə yönləndirir.

Broker 1 və 2 daha sonra Broker 3-dən ayrılır. Broker 3 öz güzgüsünü masterə təşviq etmək əvəzinə fasilə verir və əlçatmaz olur.

düyü. 23. Broker 3 bütün müştəriləri dayandırır, əlaqəni kəsir və əlaqə sorğularını rədd edir.

Bağlantı bərpa olunan kimi klasterə qayıdır.

Əsas növbənin Broker 3-də olduğu başqa bir nümunəyə baxaq.

düyü. 24. Broker 3-də əsas növbə.

Sonra eyni əlaqə itkisi baş verir. Broker 3 daha kiçik tərəfdə olduğu üçün fasilə verir. Digər tərəfdən, qovşaqlar Broker 3-ün yıxıldığını görür, buna görə də Broker 1 və 2-dən köhnə güzgü ustalığa yüksəlir.

düyü. 25. Broker 2 mövcud olmadıqda Broker 3-yə keçid.

Bağlantı bərpa edildikdə, Broker 3 klasterə qoşulacaq.

düyü. 26. Klaster normal fəaliyyətə qayıtdı.

Burada ardıcıllıq əldə etdiyimizi başa düşmək vacibdir, lakin əlçatanlığı da əldə edə bilərik, əgər biz müştəriləri bölmənin əksəriyyətinə uğurla köçürəcəyik. Əksər hallarda mən şəxsən Pause Azlıq rejimini seçərdim, lakin bu, həqiqətən fərdi vəziyyətdən asılıdır.

Mövcudluğu təmin etmək üçün müştərilərin hosta uğurla qoşulmasını təmin etmək vacibdir. Gəlin seçimlərimizə nəzər salaq.

Müştəri əlaqəsinin təmin edilməsi

Müştəriləri klasterin əsas hissəsinə və ya əlaqə itdikdən sonra (bir node nasazlığından sonra) işləyən qovşaqlara necə yönləndirmək üçün bir neçə variantımız var. Birincisi, xatırlayaq ki, müəyyən növbə müəyyən bir qovşaqda yerləşdirilir, lakin marşrutlaşdırma və siyasətlər bütün qovşaqlarda təkrarlanır. Müştərilər istənilən node-a qoşula bilər və daxili marşrutlaşdırma onları getməli olduqları yerə yönəldəcək. Lakin node dayandırıldıqda o, əlaqələri rədd edir, ona görə də müştərilər başqa qovşaqla əlaqə saxlamalıdırlar. Düyün yıxılıbsa, heç bir şey edə bilməz.

Seçimlərimiz:

• Klasterə sadəcə qovşaqlar arasında dövr edən yük balanslayıcısı vasitəsilə daxil olur və müştərilər müvəffəqiyyətli olana qədər yenidən qoşulmağa çalışırlar. Əgər qovşaq işləmirsə və ya dayandırılıbsa, o node-a qoşulmaq cəhdləri uğursuz olacaq, lakin sonrakı cəhdlər digər serverlərə gedəcək (dairəvi rejimdə). Bu, bir anlıq əlaqə itkisi və ya tez bir zamanda açılacaq bir serverin çökməsi üçün uyğundur.
• Yük balanslaşdırıcısı vasitəsilə klasterə daxil olmaq və dayandırılmış/düşmüş qovşaqların aşkar edildiyi kimi siyahıdan çıxarılması. Əgər bu, tez bir zamanda həyata keçirilərsə və müştərilər əlaqəni yenidən sınaya bilsələr, biz daimi əlçatanlıq əldə edəcəyik.
• Hər bir müştəriyə bütün qovşaqların siyahısını verin və müştəri qoşulduqda təsadüfi olaraq onlardan birini seçir. Qoşulmağa çalışarkən xəta olarsa, o, qoşulana qədər siyahıda növbəti node-a keçir.
• DNS istifadə edərək endirilmiş/dayandırılmış hostdan trafiki silin. Bu kiçik bir TTL ilə edilir.

Tapıntılar

RabbitMQ klasterləşdirmənin üstünlükləri və mənfi cəhətləri var. Ən ciddi çatışmazlıqlar bunlardır:

• klasterə qoşulduqda qovşaqlar öz məlumatlarını atırlar;
• sinxronizasiyanın bloklanması növbənin əlçatmaz olmasına səbəb olur.

Bütün çətin qərarlar bu iki memarlıq xüsusiyyətindən qaynaqlanır. Əgər RabbitMQ klasterə yenidən qoşularkən məlumatları saxlaya bilsəydi, sinxronizasiya daha sürətli olardı. Bloklanmayan sinxronizasiya qabiliyyətinə malik olsaydı, böyük növbələri dəstəkləmək daha yaxşı olardı. Bu iki problemin həlli səhvlərə dözümlü və yüksək əlçatan mesajlaşma texnologiyası kimi RabbitMQ-nun performansını xeyli yaxşılaşdıracaq. Aşağıdakı hallarda klasterləşdirmə ilə RabbitMQ tövsiyə etməkdə tərəddüd edərdim:

• Etibarsız şəbəkə.
• Etibarsız saxlama.
• Çox uzun xətlər.

Yüksək əlçatanlıq parametrlərinə gəldikdə, bunları nəzərə alın:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Və ya autoheal)
• davamlı mesajlar
• bəzi node aşağı düşdükdə müştərilərin aktiv node ilə əlaqə saxladığından əmin olun

Ardıcıllıq (məlumat təhlükəsizliyi) üçün aşağıdakı parametrləri nəzərdən keçirin:

• İstehlakçı tərəfdə Nəşriyyat Təsdiqləri və Əl Təşəkkürləri
• ha-promote-on-failure=when-syncednaşirlər daha sonra yenidən cəhd edə bilərsə və çox güclü yaddaşınız varsa! Əks halda qoyun =always.
• ha-sync-mode=automatic (lakin böyük qeyri-aktiv növbələr manuel rejim tələb edə bilər; həmçinin, əlçatmazlığın mesajların itirilməsinə səbəb olub-olmadığını düşünün)
• Azlıq rejimini dayandırın
• davamlı mesajlar

Biz hələ də qüsurlara dözümlülük və yüksək əlçatanlıq məsələlərini əhatə etməmişik; məsələn, inzibati prosedurları (məsələn, yayma yeniləmələr kimi) təhlükəsiz yerinə yetirmək. Biz həmçinin federasiya və Shovel plaginindən danışmalıyıq.

Başqa bir şeyi əldən vermişəmsə, zəhmət olmasa, mənə bildirin.

Mənimkilərə də baxın yazıburada bu məqalədə təsvir olunan bəzi mesaj itkisi ssenarilərini sınamaq üçün Docker və Blockade ilə RabbitMQ klasterini pozuram.

Serialdakı əvvəlki məqalələr:
№1 - habr.com/ru/company/itsumma/blog/416629
№2 - habr.com/ru/company/itsumma/blog/418389
№3 - habr.com/ru/company/itsumma/blog/437446

Mənbə: www.habr.com