Алдаа тэсвэрлэх чадвар, өндөр хүртээмж нь том сэдэв тул бид RabbitMQ болон Kafka-д тусдаа өгүүлэл зориулах болно. Энэ нийтлэл нь RabbitMQ-ийн тухай, дараагийнх нь RabbitMQ-тай харьцуулахад Кафкагийн тухай юм. Энэ бол урт нийтлэл тул өөрийгөө тухтай байлгаарай.
Гэмтлийг тэсвэрлэх чадвар, тууштай байдал, өндөр хүртээмжтэй байх (HA) стратеги болон стратеги тус бүрээр бий болгодог өөрчлөлтүүдийг харцгаая. RabbitMQ нь зангилааны кластер дээр ажиллах боломжтой бөгөөд дараа нь тархсан систем гэж ангилагдана. Түгээмэл системүүдийн тухайд бид байнга тууштай байдал, хүртээмжтэй байдлын талаар ярьдаг.
Эдгээр ойлголтууд нь систем бүтэлгүйтсэн үед хэрхэн ажиллахыг тодорхойлдог. Сүлжээний холболтын доголдол, серверийн доголдол, хатуу дискний доголдол, хог цуглуулах, пакет алдагдах эсвэл сүлжээний холболт удаашрах зэргээс шалтгаалан сервер түр ажиллахгүй байх. Энэ бүхэн нь өгөгдлийн алдагдал эсвэл зөрчилд хүргэж болзошгүй юм. Бүх бүтэлгүйтлийн хувилбарт бүрэн нийцтэй (өгөгдлийн алдагдалгүй, өгөгдлийн ялгаа байхгүй), боломжтой (унших, бичихийг зөвшөөрдөг) системийг бий болгох нь бараг боломжгүй юм.
Тогтвортой байдал, хүртээмж нь спектрийн эсрэг талд байгааг бид харах болно, та аль аргыг оновчтой болгохоо сонгох хэрэгтэй. Сайн мэдээ гэвэл RabbitMQ-ийн тусламжтайгаар энэ сонголтыг хийх боломжтой. Танд тэнцвэрийг илүү тогтвортой байдал эсвэл илүү хүртээмжтэй болгохын тулд ийм төрлийн "ердийн" хөшүүрэг байдаг.
Баталгаажсан бүртгэлээс болж ямар тохиргоо өгөгдлийн алдагдалд хүргэж байгааг бид онцгой анхаарах болно. Нийтлэгч, брокер, хэрэглэгчдийн хооронд хариуцлагын гинжин хэлхээ бий. Зурвасыг брокер руу дамжуулсны дараа мессежийг алдахгүй байх нь түүний үүрэг юм. Брокер нь нийтлэгчээс мессеж хүлээн авсныг хүлээн зөвшөөрөх үед бид үүнийг алдахгүй гэж найдаж байна. Гэхдээ энэ нь таны брокер болон нийтлэгчийн тохиргооноос хамаарч тохиолдож болохыг бид харах болно.
Нэг зангилааны уян хатан байдлын командууд
Тохиромжтой дараалал/чиглүүлэлт
RabbitMQ-д удаан эдэлгээтэй ба бат бөх бус гэсэн хоёр төрлийн дараалал байдаг. Бүх дарааллыг Mnesia мэдээллийн санд хадгалдаг. Зангилаа эхлүүлэх үед удаан эдэлгээтэй дарааллыг дахин сурталчлах бөгөөд ингэснээр дахин ачаалах, системийн эвдрэл эсвэл серверийн эвдрэлийг даван туулах болно (өгөгдөл хадгалагдаагүй л бол). Энэ нь таныг чиглүүлэлт (солилцоо) болон дараалалд тэсвэртэй гэж зарласан л бол дараалал/чиглүүлэлтийн дэд бүтэц дахин онлайн болно гэсэн үг юм.
Зангилааг дахин эхлүүлэх үед тогтворгүй дараалал болон чиглүүлэлт арилдаг.
Байнгын мессежүүд
Дараалал нь удаан эдэлгээтэй байна гэдэг нь зангилааг дахин эхлүүлэх үед түүний бүх мессежүүд үлдэнэ гэсэн үг биш юм. Зөвхөн нийтлэгчийн тохируулсан мессежүүд тогтвортой (тогтвортой). Байнгын зурвасууд нь брокер дээр нэмэлт ачаалал үүсгэдэг боловч хэрэв мессежийн алдагдал хүлээн зөвшөөрөгдөхгүй бол өөр сонголт байхгүй болно.
Цагаан будаа. 1. Тогтвортой байдлын матриц
Дараалал толин тусгал бүхий кластер
Зуучлагчаа алдсанаас амьд үлдэхийн тулд бидэнд орон тооны цомхотгол хэрэгтэй. Бид хэд хэдэн RabbitMQ зангилааг кластерт нэгтгэж, дараа нь олон зангилааны хооронд дарааллыг хуулбарлах замаар нэмэлт нөөц нэмж болно. Ингэснээр нэг зангилаа бүтэлгүйтвэл бид өгөгдлийг алдахгүй бөгөөд бэлэн хэвээр үлдэнэ.
Дарааллын толин тусгал:
- бичих, унших бүх командыг хүлээн авдаг нэг үндсэн дараалал (мастер).
- үндсэн дарааллаас бүх мессеж, мета өгөгдлийг хүлээн авдаг нэг буюу хэд хэдэн толь. Эдгээр толин тусгалууд нь томрохын тулд биш, харин зөвхөн илүүдлийн төлөө байдаг.
Цагаан будаа. 2. Дарааллын толин тусгал
Толин тусгал нь зохих бодлогоор тогтоогддог. Үүн дээр та хуулбарлах коэффициент, тэр ч байтугай дараалал байрлах зангилааг сонгох боломжтой. Жишээ нь:
ha-mode: allha-mode: exactly, ha-params: 2(нэг мастер, нэг толь)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Нийтлэгчийн баталгаажуулалт
Тогтвортой бичлэг хийхийн тулд Нийтлэгчийн баталгаажуулалт шаардлагатай. Тэдгээргүйгээр мессеж алга болох эрсдэлтэй. Мессежийг дискэнд бичсэний дараа баталгаажуулалтыг хэвлэн нийтлэгчид илгээдэг. RabbitMQ нь мессежийг хүлээн авсны дараа биш, харин үе үе хэдэн зуун миллисекундын бүсэд бичдэг. Дарааллыг толин тусгал болгох үед бүх толин тусгалууд мессежийн хуулбарыг дискэнд бичсэний дараа л хүлээн зөвшөөрөгддөг. Энэ нь баталгаажуулалтыг ашиглах нь хоцролтыг нэмэгдүүлдэг боловч өгөгдлийн аюулгүй байдал чухал бол тэдгээр нь зайлшгүй шаардлагатай гэсэн үг юм.
Гүйцэтгэх дараалал
Брокер ажиллахаа болих эсвэл эвдрэх үед тэр зангилааны бүх дарааллын удирдагчид (мастерууд) түүнтэй хамт гацдаг. Дараа нь кластер нь мастер бүрийн хамгийн эртний толийг сонгож, шинэ мастер болгон сурталчилдаг.
Цагаан будаа. 3. Олон толин тусгалтай дараалал ба тэдгээрийн бодлого
Брокер 3 унана. Брокер 2 дээрх Queue C толин тусгалыг мастерт дэвшүүлж байгааг анхаарна уу. Брокер 1 дээрх C Queue-д зориулж шинэ толь үүсгэсэн болохыг анхаарна уу. RabbitMQ нь таны бодлогод заасан хуулбарын хүчин зүйлийг хадгалахыг үргэлж оролддог.
Цагаан будаа. 4. Брокер 3 амжилтгүй болж, C дараалал амжилтгүй болсон
Дараагийн Брокер 1 унав! Манайд ганц брокер үлдлээ. Queue B толин тусгалыг мастерт дэвшүүлэв.
Зураг. 5
Бид брокер 1-ийг буцаасан. Брокер алдагдаж, сэргээгдэх үед өгөгдөл хэр сайн хадгалагдаж байгаагаас үл хамааран бүх толин тусгалтай дарааллын мессежийг дахин эхлүүлэх үед устгана. Үр дагавар гарах тул үүнийг анхаарах нь чухал юм. Бид эдгээр үр дагаврыг удахгүй авч үзэх болно. Тиймээс 1-р брокер одоо дахин кластерын гишүүн болсон бөгөөд кластер нь бодлогыг дагаж мөрдөхийг оролддог тул 1-р брокер дээр толин тусгал үүсгэдэг.
Энэ тохиолдолд брокер 1-ийн алдагдал нь өгөгдөлтэй адил бүрэн байсан тул толин тусгалгүй В дараалал бүрэн алдагдсан.
Цагаан будаа. 6. Брокер 1 үйлчилгээнд буцаж ирэв
Брокер 3 дахин онлайн болсон тул А болон В дараалал нь HA бодлогоо хангахын тулд үүн дээр үүсгэсэн толин тусгалыг буцааж авна. Гэхдээ одоо бүх гол дараалал нэг зангилаа дээр байна! Энэ нь тийм ч тохиромжтой биш, зангилааны хооронд жигд хуваарилалт нь илүү дээр юм. Харамсалтай нь энд мастеруудыг тэнцвэржүүлэх олон сонголт байдаггүй. Бид эхлээд дарааллын синхрончлолыг харах хэрэгтэй тул дараа нь энэ асуудалд эргэн орох болно.
Цагаан будаа. 7. Брокер 3 үйлчилгээнд буцаж ирэв. Бүх үндсэн дараалууд нэг зангилаа дээр!
Тиймээс одоо та толин тусгал нь илүүдэл болон алдааг тэсвэрлэх чадварыг хэрхэн хангадаг талаар ойлголттой байх ёстой. Энэ нь нэг зангилаа эвдэрсэн тохиолдолд бэлэн байдлыг баталгаажуулж, өгөгдөл алдагдахаас хамгаална. Гэхдээ бид хараахан дуусаагүй байна, учир нь бодит байдал дээр энэ нь илүү төвөгтэй байдаг.
Синхрончлол
Шинэ толь үүсгэх үед бүх шинэ мессежүүд үргэлж энэ толинд болон бусад бүх толинд хуулбарлагдах болно. Мастер дараалалд байгаа өгөгдлийн хувьд бид үүнийг шинэ толинд хуулбарлах боломжтой бөгөөд энэ нь мастерын бүрэн хуулбар болно. Мөн бид одоо байгаа мессежүүдийг давтахгүй байхаар сонгож, үндсэн дараалал болон шинэ толин тусгалыг цаг тухайд нь нэгтгэж, шинэ мессежүүд сүүл рүү нь ирж, одоо байгаа мессежүүд үндсэн дарааллын толгойг орхиж болно.
Энэ синхрончлолыг автоматаар эсвэл гараар хийдэг бөгөөд дарааллын бодлогыг ашиглан удирддаг. Нэг жишээ авч үзье.
Бидэнд толин тусгалтай хоёр дараалал бий. А дараалал автоматаар синхрончлогдоно, Б дараалал гараар синхрончлогддог. Хоёр дараалалд арван зурвас байна.
Цагаан будаа. 8. Өөр өөр синхрончлолын горимтой хоёр дараалал
Одоо бид Брокер 3-ыг алдаж байна.
Цагаан будаа. 9. Брокер 3 унав
Брокер 3 үйлчилгээнд буцаж ирлээ. Кластер нь шинэ зангилааны дараалал бүрт толин тусгал үүсгэж, шинэ А дарааллыг мастертай автоматаар синхрончилдог. Гэсэн хэдий ч шинэ В дарааллын толь хоосон хэвээр байна. Ингэснээр бид А дараалалд бүрэн нөөцөлж, одоо байгаа B дарааллын мессежүүдэд зөвхөн нэг толин тусгалтай болно.
Цагаан будаа. 10. А дарааллын шинэ толин тусгал нь одоо байгаа бүх мессежийг хүлээн авдаг бол В дарааллын шинэ толь хүлээж авдаггүй.
Хоёр дараалалд дахиад арван мессеж ирдэг. Дараа нь 2-р брокер эвдэрч, дараалал А нь Брокер 1-д байгаа хамгийн эртний толин тусгал руу буцна. Энэ нь амжилтгүй болсон үед өгөгдөл алдагдахгүй. В дараалалд мастерт хорин зурвас, толинд ердөө аравхан зурвас байна, учир нь энэ дараалал нь анхны арван мессежийг хэзээ ч давтаагүй.
Цагаан будаа. 11. Queue A нь мессеж алдалгүйгээр брокер 1 рүү буцдаг
Хоёр дараалалд дахиад арван мессеж ирдэг. Одоо Broker 1 гацаж байна. A Queue нь мессежээ алдалгүйгээр толинд амархан шилждэг. Гэсэн хэдий ч В дараалал асуудалтай байна. Энэ үед бид хүртээмж, тууштай байдлыг оновчтой болгож чадна.
Хэрэв бид хүртээмжийг оновчтой болгохыг хүсч байвал бодлого га-бүтэлгүйтлийг дэмжих -д суурилуулсан байх ёстой үргэлж. Энэ нь өгөгдмөл утга учир та бодлогыг огт зааж өгөх боломжгүй. Энэ тохиолдолд бид үндсэндээ синхрончлолгүй толин тусгалуудад алдаа гарахыг зөвшөөрдөг. Энэ нь мессежийг алдахад хүргэх боловч дараалал нь унших, бичих боломжтой хэвээр байх болно.
Цагаан будаа. 12. А дарааллыг зурвас алдалгүйгээр Брокер 3 руу буцаана. Б дараалал нь арван мессеж алдагдсанаар Брокер 3 руу буцна
Бид бас суулгаж болно ha-promote-on-failure утга руу оруулна when-synced. Энэ тохиолдолд толин тусгал руу буцахын оронд дараалал нь 1-р брокер өгөгдөлтэйгээ онлайн горимд буцаж ирэх хүртэл хүлээх болно. Буцаж ирсний дараа үндсэн дараалал нь өгөгдлийн алдагдалгүйгээр Брокер 1 дээр буцаж ирнэ. Өгөгдлийн аюулгүй байдлын үүднээс хүртээмжийг золиослодог. Гэхдээ энэ нь эрсдэлтэй горим бөгөөд бид удахгүй авч үзэх болно.
Цагаан будаа. 13. Брокер 1-ийг алдсаны дараа В дараалал боломжгүй хэвээр байна
Та "Автомат синхрончлолыг хэзээ ч ашиглахгүй байх нь дээр гэж үү?" Хариулт нь синхрончлол нь хаах үйлдэл юм. Синхрончлолын үед үндсэн дараалал нь унших, бичих үйлдлийг гүйцэтгэх боломжгүй!
Нэг жишээ авч үзье. Одоо бид маш урт дараалалтай байна. Тэд яаж ийм хэмжээтэй болж өсөх вэ? Хэд хэдэн шалтгааны улмаас:
- Дараалалыг идэвхтэй ашигладаггүй
- Эдгээр нь өндөр хурдны дараалал бөгөөд яг одоо хэрэглэгчид удаашралтай байна
- Энэ бол өндөр хурдны дараалал, алдаа гарсан бөгөөд хэрэглэгчид үүнийг гүйцэж байна
Цагаан будаа. 14. Өөр өөр синхрончлолын горимтой хоёр том дараалал
Одоо Брокер 3 унаж байна.
Цагаан будаа. 15. Зуучлагч 3 унаж, дараалал бүрт нэг мастер, толь үлдээдэг
Брокер 3 дахин онлайн болж, шинэ толь бий болсон. Үндсэн дараалал А одоо байгаа мессежүүдийг шинэ толинд хуулбарлаж эхэлдэг бөгөөд энэ хугацаанд дараалал боломжгүй байна. Өгөгдлийг хуулбарлахад хоёр цаг шаардагдах бөгөөд ингэснээр энэ дараалал хоёр цаг ажиллахгүй болно!
Гэсэн хэдий ч В дараалал бүх хугацаанд боломжтой хэвээр байна. Тэрээр хүртээмжтэй байхын тулд зарим нэг илүүдлийг золиосолжээ.
Цагаан будаа. 16. Синхрончлолын үед дараалал боломжгүй хэвээр байна
Хоёр цагийн дараа А дараалал бас боломжтой болж, унших, бичихийг дахин хүлээн авч эхлэх боломжтой.
Шинэчлэлтүүд
Синхрончлолын үед блоклох үйлдэл нь маш том дараалал бүхий кластеруудыг шинэчлэхэд хэцүү болгодог. Хэзээ нэгэн цагт мастер зангилааг дахин эхлүүлэх шаардлагатай бөгөөд энэ нь серверийг шинэчлэх үед толин тусгал руу шилжих эсвэл дарааллыг идэвхгүй болгох гэсэн үг юм. Хэрэв бид шилжилтийг сонговол толин тусгалууд синхрончлогдоогүй бол мессежээ алдах болно. Өгөгдмөл байдлаар, брокерын саатлын үед синхрончлолгүй толин тусгал руу шилжүүлэлт хийгддэггүй. Энэ нь брокер буцаж ирмэгц бид ямар ч мессеж алдахгүй, цорын ганц хохирол нь энгийн дараалал байсан гэсэн үг юм. Брокерыг салгах үед ажиллах дүрмийг бодлогоор тогтоодог ha-promote-on-shutdown. Та хоёр утгын аль нэгийг тохируулж болно:
always= синхрон бус толь руу шилжих шилжилт идэвхжсэнwhen-synced= зөвхөн синхрон толин тусгал руу шилжих, эс тэгвээс дараалал нь унших боломжгүй, бичих боломжгүй болно. Брокер буцаж ирмэгц дараалал нь үйлчилгээнд буцаж ирдэг
Ямар нэгэн байдлаар, том дараалалтай үед та өгөгдөл алдагдах, ашиглах боломжгүй байдлын аль нэгийг сонгох хэрэгтэй.
Хэзээ олдоц нь мэдээллийн аюулгүй байдлыг сайжруулдаг
Шийдвэр гаргахын өмнө анхаарах ёстой өөр нэг хүндрэл бий. Автомат синхрончлол нь нөөцлөхөд илүү сайн байдаг ч энэ нь мэдээллийн аюулгүй байдалд хэрхэн нөлөөлдөг вэ? Мэдээжийн хэрэг, илүү сайн нөөцтэй бол RabbitMQ одоо байгаа мессежийг алдах магадлал багатай, гэхдээ нийтлэгчдийн шинэ мессежийг яах вэ?
Энд та дараахь зүйлийг анхаарч үзэх хэрэгтэй.
- Нийтлэгч зүгээр л алдаа гаргаж, дээд үйлчилгээ эсвэл хэрэглэгч дараа дахин оролдох боломжтой юу?
- Нийтлэгч мессежийг дотооддоо эсвэл мэдээллийн санд хадгалж, дараа дахин оролдох боломжтой юу?
Хэрэв нийтлэгч зөвхөн мессежийг хаяж чадвал хүртээмжийг сайжруулах нь мэдээллийн аюулгүй байдлыг сайжруулдаг.
Тиймээс тэнцвэрийг эрэлхийлэх ёстой бөгөөд шийдэл нь тодорхой нөхцөл байдлаас хамаарна.
Ha-promote-on-failure=when-синктэй холбоотой асуудлууд
Санаа га-бүтэлгүйтлийг дэмжих= синк хийгдсэн үед Бид синхрон бус толин тусгал руу шилжихээс сэргийлж, мэдээллийн алдагдлаас сэргийлдэг. Дараалал нь унших боломжгүй эсвэл бичих боломжгүй хэвээр байна. Үүний оронд бид осолдсон брокерийг өгөгдөл нь бүрэн бүтэн байдлаар сэргээхийг оролддог бөгөөд ингэснээр өгөгдлийг алдагдуулахгүйгээр мастераар ажиллах боломжтой болно.
Гэхдээ (мөн энэ нь том боловч) хэрэв брокер мэдээллээ алдсан бол бидэнд том асуудал байна: дараалал алдагдсан! Бүх өгөгдөл алга болсон! Хэдийгээр та үндсэн дарааллыг гүйцэх тольтой байсан ч тэдгээр толин тусгалыг бас хаядаг.
Ижил нэртэй зангилааг дахин нэмэхийн тулд бид кластерт алдагдсан зангилаа мартахыг хэлдэг (командын тусламжтайгаар). rabbitmqctl мартах_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. Администратор нь Broker 3-ыг идэвхгүй болгосон.
Цагаан будаа. 21. Администратор Broker 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=alwaysha-sync-mode=manualcluster_partition_handling=ignore(эсвэлautoheal)- байнгын мессежүүд
- Зарим зангилаа бүтэлгүйтсэн үед үйлчлүүлэгчид идэвхтэй зангилаатай холбогдоно
Тогтвортой байхын тулд (өгөгдлийн аюулгүй байдал) дараах тохиргоог анхаарч үзээрэй.
- Хэрэглэгчийн тал дээр нийтлэгч баталгаажуулж, гарын авлагын талархал
ha-promote-on-failure=when-synced, хэрэв нийтлэгчид дараа дахин оролдох боломжтой бөгөөд танд маш найдвартай хадгалах сан байгаа бол! Үгүй бол тавь=always.ha-sync-mode=automatic(гэхдээ идэвхгүй том дарааллын хувьд гарын авлагын горим шаардлагатай байж болно; мөн ашиглах боломжгүй байгаа нь мессеж алдагдах эсэхийг анхаарч үзээрэй)- Цөөнхийн горимыг түр зогсоох
- байнгын мессежүүд
Бид алдааг тэсвэрлэх чадвар, өндөр хүртээмжтэй байдлын бүх асуудлыг хараахан авч үзээгүй байна; жишээ нь, захиргааны процедурыг хэрхэн найдвартай гүйцэтгэх (шинэчлэлт хийх гэх мэт). Бид мөн холбоо болон хүрз залгаасын талаар ярих хэрэгтэй.
Хэрэв надад өөр зүйл дутуу байвал надад мэдэгдээрэй.
Мөн миний , би энэ нийтлэлд тайлбарласан мессеж алдагдах зарим хувилбаруудыг туршихын тулд Docker болон Blockade ашиглан RabbitMQ кластер дээр сүйрэл хийж байна.
Цувралын өмнөх нийтлэлүүд:
№1 -
№2 -
№3 -
Эх сурвалж: www.habr.com