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

Энд хуулбарлах нэгж нь хуваалт юм. Сэдэв бүр нэг буюу хэд хэдэн хэсэгтэй. Хэсэг бүр дагагчтай эсвэл дагагчгүй удирдагчтай. Сэдвийг үүсгэхдээ хуваалтын тоо, хуулбарлах коэффициентийг зааж өгнө. Ердийн утга нь 3 бөгөөд энэ нь нэг удирдагч, хоёр дагагч гэсэн гурван хуулбар гэсэн үг юм.

Цагаан будаа. 1. Дөрвөн хэсэг нь гурван брокерын дунд хуваарилагдсан

Унших, бичих бүх хүсэлт удирдагч руу очдог. Дагагчид үе үе удирдагч руу хамгийн сүүлийн үеийн мессежийг хүлээн авах хүсэлт илгээдэг. Хэрэглэгчид хэзээ ч дагалдагчдад ханддаггүй; сүүлийнх нь зөвхөн илүүдэл, алдааг тэсвэрлэхийн тулд л байдаг.

Хуваалтын алдаа

Брокер бүтэлгүйтсэн тохиолдолд хэд хэдэн хэсгийн удирдагчид бүтэлгүйтдэг. Тэд тус бүрт өөр зангилааны дагалдагч удирдагч болдог. Үнэн хэрэгтээ энэ нь үргэлж тийм байдаггүй, учир нь синхрончлолын хүчин зүйл нь мөн нөлөөлдөг: синхрончлогдсон дагалдагчид байгаа эсэх, хэрэв байхгүй бол синхрончлолгүй хуулбар руу шилжихийг зөвшөөрдөг. Гэхдээ одоохондоо асуудлыг төвөгтэй болгох хэрэггүй.

Брокер 3 сүлжээг орхиж, 2-р брокерын 2-р хэсэгт шинэ удирдагч сонгогдоно.

Цагаан будаа. 2. Брокер 3 нас барж, 2-р брокер дээрх түүний дагалдагч 2-р хэсгийн шинэ удирдагчаар сонгогдов.

Дараа нь 1-р брокер орхиж, 1-р хэсэг нь удирдагчаа алдаж, үүрэг нь 2-р брокерт шилждэг.

Цагаан будаа. 3. Нэг брокер үлдлээ. Бүх удирдагчид нэг брокер дээр байдаг бөгөөд тэг илүүдэлтэй

1-р брокер онлайнаар буцаж ирэхэд дөрвөн дагагч нэмж, хуваалт бүрт тодорхой хэмжээний нэмэгдэл өгдөг. Гэхдээ бүх удирдагчид 2-р брокер дээр үлдсэн.

Цагаан будаа. 4. Удирдагчид 2-р брокер дээр үлдэнэ

Брокер 3 гарч ирэхэд бид хуваалт бүрт гурван хуулбар руу буцна. Гэхдээ бүх удирдагчид 2-р брокер дээр хэвээр байна.

Цагаан будаа. 5. 1 ба 3-р брокеруудыг сэргээсний дараа удирдагчдыг тэнцвэргүй байрлуулах

Кафка нь RabbitMQ-аас илүү удирдагчийг тэнцвэржүүлэх хэрэгсэлтэй. Тэнд та шилжилтийн явцад илүүдлийг багасгах замаар мастер зангилааг шилжүүлэх бодлогыг өөрчилсөн гуравдагч талын залгаас эсвэл скрипт ашиглах шаардлагатай болсон. Нэмж дурдахад, том дарааллын хувьд бид синхрончлолын явцад боломжгүй байдлыг хүлээн зөвшөөрөх шаардлагатай болсон.

Кафка удирдагчийн дүрд "доорх хуулбар" гэсэн ойлголттой байдаг. Сэдвийн хуваалтуудыг үүсгэх үед Кафка удирдагчдыг зангилаанд жигд хуваарилахыг оролддог бөгөөд тэдгээр эхний удирдагчдыг илүүд үздэг гэж тэмдэглэдэг. Цаг хугацаа өнгөрөхөд сервер дахин ачаалагдах, доголдол болон холболтын эвдрэл зэргээс шалтгаалан удирдагчид дээр дурдсан онцгой тохиолдлын адил бусад зангилаанууд дээр дуусч болно.

Үүнийг засахын тулд Кафка хоёр сонголтыг санал болгож байна:

• Сонголт auto.leader.rebalance.enable=true хянагчийн зангилаа нь удирдагчдыг сонгосон хуулбарууд руу автоматаар дахин хуваарилж, улмаар жигд хуваарилалтыг сэргээх боломжийг олгодог.
• Администратор скриптийг ажиллуулж болно kafka-preferred-replica-section.sh гараар дахин томилоход зориулагдсан.

Цагаан будаа. 6. Тэнцвэржүүлсний дараах хуулбарууд

Энэ нь бүтэлгүйтлийн хялбаршуулсан хувилбар байсан боловч бодит байдал нь илүү төвөгтэй боловч энд хэтэрхий төвөгтэй зүйл байхгүй. Энэ бүхэн нь синхрончлогдсон хуулбар (In-Sync Replicas, ISR) дээр ирдэг.

Синхрон хуулбар (ISR)

ISR нь "синхрончлогдсон" (синк хийсэн) гэж тооцогддог хуваалтын хуулбаруудын багц юм. Удирдагч байдаг ч дагагч байхгүй байж болно. Завсарлага дуусахаас өмнө удирдагчийн бүх мессежийг яг хуулбарласан бол дагагч нь синхрончлогдсон гэж тооцогддог. replica.lag.time.max.ms.

Дараах тохиолдолд дагагчийг ISR багцаас хасна.

• интервалыг сонгох хүсэлт гаргаагүй replica.lag.time.max.ms (үхсэн гэж таамаглаж байна)
• завсарлагааны хугацаанд шинэчилж чадаагүй replica.lag.time.max.ms (удаан гэж үздэг)

Дагагчид интервалаар дээж авах хүсэлт гаргадаг replica.fetch.wait.max.ms, энэ нь анхдагчаар 500ms байна.

ISR-ийн зорилгыг тодорхой тайлбарлахын тулд бид үйлдвэрлэгчийн баталгаажуулалт болон бүтэлгүйтлийн зарим хувилбаруудыг үзэх хэрэгтэй. Брокер баталгаажуулалтыг илгээх үед үйлдвэрлэгчид сонгох боломжтой:

• acks=0, баталгаажуулалтыг илгээгээгүй
• acks=1, удирдагч орон нутгийн бүртгэлдээ мессеж бичсэний дараа баталгаажуулалт илгээгдэнэ
• acks=all, ISR дээрх бүх хуулбарууд локал бүртгэлд мессеж бичсэний дараа баталгаажуулалт илгээгдэнэ

Кафкагийн нэр томъёогоор, хэрэв ISR нь мессежийг хадгалсан бол энэ нь "commited" гэсэн үг юм. Acks=all бол хамгийн найдвартай сонголт боловч нэмэлт саатал нэмдэг. Бүтэлгүйтлийн хоёр жишээг авч үзье, янз бүрийн 'acks' сонголтууд ISR үзэл баримтлалтай хэрхэн харьцаж байгааг харцгаая.

Acks=1 ба ISR

Энэ жишээн дээр хэрэв удирдагч бүх дагалдагчдын мессеж бүрийг хадгалахыг хүлээхгүй бол удирдагч амжилтгүй болбол өгөгдөл алдагдах боломжтой гэдгийг бид харах болно. Синк хийгдээгүй дагагч руу шилжихийг тохиргоогоор идэвхжүүлж эсвэл идэвхгүй болгож болно бузар.удирдагч.сонгууль.идэвхжүүлэх.

Энэ жишээнд үйлдвэрлэгч acks=1 гэсэн утгатай байна. Энэ хэсэг нь бүх гурван брокерт хуваарилагдсан. Брокер 3 хоцорч, найман секундын өмнө тэргүүлэгчтэй синхрончлогдсон бөгөөд одоо 7456 мессежээр хоцорч байна. Брокер 1 ердөө нэг секундээр хоцорч байсан. Манай продюсер мессеж илгээж, удирдагчийн хүлээхгүй удаан эсвэл үхсэн дагалдагчдад дарамт учруулахгүйгээр хурдан хариу хүлээн авдаг.

Цагаан будаа. 7. Гурван хуулбартай ISR

Брокер 2 амжилтгүй болж, үйлдвэрлэгч холболтын алдаа хүлээн авдаг. Манлайлал 1-р брокер руу шилжсэний дараа бид 123 мессежийг алддаг. Брокер 1 дээрх дагагч нь ISR-ийн нэг хэсэг байсан боловч унах үед удирдагчтай бүрэн синхрончлогдоогүй.

Цагаан будаа. 8. Гэмтсэн үед мессеж алга болдог

Тохиргоонд байна bootstrap.servers Үйлдвэрлэгч хэд хэдэн брокерын жагсаалтад орсон бөгөөд шинэ хэсгийн ахлагч болох өөр брокероос асууж болно. Дараа нь брокер 1-тэй холбогдож, мессеж илгээсээр байна.

Цагаан будаа. 9. Богино хугацааны завсарлагааны дараа мессеж илгээх ажиллагаа үргэлжилнэ

Брокер 3 нь бүр ч хоцорч байна. Энэ нь дуудах хүсэлт гаргадаг боловч синк хийх боломжгүй. Энэ нь брокеруудын хоорондын сүлжээний холболт удаашрал, хадгалалтын асуудал гэх мэттэй холбоотой байж болох юм. Энэ нь ISR-ээс хасагдсан. Одоо ISR нь нэг хуулбараас бүрддэг - удирдагч! Үйлдвэрлэгч мессеж илгээж, баталгаажуулалтыг хүлээн авсаар байна.

Цагаан будаа. 10. Брокер 3 дээрх дагагчийг ISR-ээс хассан

Брокер 1 буурч, манлайллын үүрэг 3 мессеж алдагдсанаар 15286-р брокерт очно! Үйлдвэрлэгч холболтын алдааны мессеж хүлээн авдаг. ISR-ээс гадуур удирдагч руу шилжих нь зөвхөн тохируулгын улмаас боломжтой байсан unclean.leader.election.enable=true. Хэрэв суулгасан бол хуурамч, дараа нь шилжилт хийгдэхгүй бөгөөд бүх унших, бичих хүсэлтээс татгалзах болно. Энэ тохиолдолд бид 1-р брокер өөрийн бүрэн бүтэн өгөгдлийн хуулбарт буцаж ирэхийг хүлээж байгаа бөгөөд энэ нь манлайллыг дахин авах болно.

Цагаан будаа. 11. Брокер 1 унав. Алдаа гарсан тохиолдолд олон тооны мессеж алга болно

Продюсер нь сүүлчийн брокертой холбоо тогтоож, тэр одоо хэсгийн ахлагч болж байгааг хардаг. Тэрээр 3-р брокер руу мессеж илгээж эхэлдэг.

Цагаан будаа. 12. Богино завсарлага авсны дараа 0-р хэсэг рүү мессежүүд дахин илгээгдэнэ

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

Acks=all ба ISR

Энэ хувилбарыг дахин давтъя, гэхдээ хамт acks=бүгд. Брокер 3 нь дунджаар дөрвөн секундын хоцрогдолтой байдаг. Үйлдвэрлэгч нь мессеж илгээдэг acks=бүгд, одоо хурдан хариу хүлээж авахгүй байна. Удирдагч ISR дахь бүх хуулбаруудаар мессежийг хадгалахыг хүлээж байна.

Цагаан будаа. 13. Гурван хуулбартай ISR. Нэг нь удаашралтай байгаа нь бичлэгийн саатал үүсгэдэг

Дөрвөн секундын нэмэлт саатлын дараа брокер 2 акк илгээнэ. Бүх хуулбарууд одоо бүрэн шинэчлэгдсэн.

Цагаан будаа. 14. Бүх хуулбарууд мессежийг хадгалж, акк илгээдэг

Брокер 3 одоо илүү хоцорч, ISR-ээс хасагдсан. ISR-д удаан хуулбар байхгүй тул хоцролт нь мэдэгдэхүйц багасдаг. Брокер 2 одоо зөвхөн 1-р брокерыг хүлээж байгаа бөгөөд дунджаар 500 мс хоцрогдолтой байна.

Цагаан будаа. 15. Брокер 3 дээрх хуулбарыг ISR-ээс хассан

Дараа нь 2-р брокер унаж, манлайлал 1-р брокер руу мессеж алдалгүй шилждэг.

Цагаан будаа. 16. Брокер 2 унав

Үйлдвэрлэгч шинэ удирдагч олж, түүнд мессеж илгээж эхэлдэг. ISR нь одоо нэг хуулбараас бүрдэх тул хоцролт нь улам багассан! Тиймээс сонголт acks=бүгд илүүдэл нэмэхгүй.

Цагаан будаа. 17. Брокер 1 дээрх хуулбар нь мессежийг алдалгүйгээр тэргүүлдэг

Дараа нь брокер 1 эвдэрч, хар тугалга нь 3 мессежийн алдагдалтай 14238-р брокер руу очно!

Цагаан будаа. 18. Брокер 1 нас барж, манлайлал нь цэвэр бус тохиргоотой шилжилтийн үр дүнд их хэмжээний мэдээлэл алдагдахад хүргэдэг

Бид сонголтыг суулгаж чадсангүй бузар.удирдагч.сонгууль.идэвхжүүлэх утга руу оруулна үнэн. Анхдагчаар энэ нь тэнцүү байна хуурамч. Тохиргоо acks=бүгд с unclean.leader.election.enable=true зарим нэмэлт мэдээллийн аюулгүй байдлын тусламжтайгаар хүртээмжтэй байдлыг хангадаг. Гэхдээ таны харж байгаагаар бид мессежээ алдаж болно.

Гэхдээ бид мэдээллийн аюулгүй байдлыг нэмэгдүүлэхийг хүсвэл яах вэ? Та тавьж болно unclean.leader.election.enable = худал, гэхдээ энэ нь биднийг өгөгдөл алдагдахаас хамгаалах албагүй. Хэрэв удирдагч хүчтэй унаж, өгөгдлийг авч явсан бол администратор нөхцөл байдлыг сэргээх хүртэл мессеж алга болсон хэвээр байна.

Бүх мессежийг илүүд үзэх, эс тэгвээс бичлэгийг хаях нь дээр. Дараа нь, наад зах нь брокерын үүднээс авч үзвэл, өгөгдөл алдагдах нь зөвхөн хоёр ба түүнээс дээш зэрэг алдаа гарсан тохиолдолд л боломжтой юм.

Acks=all, min.insync.replicas болон ISR

Сэдвийн тохиргоотой min.insync.replicas Бид мэдээллийн аюулгүй байдлын түвшинг дээшлүүлж байна. Өмнөх хувилбарын сүүлчийн хэсгийг дахин авч үзье, гэхдээ энэ удаад min.insync.replicas=2.

Тиймээс 2-р брокер нь хуулбар удирдагчтай бөгөөд 3-р брокер дээрх дагагч нь ISR-ээс хасагдсан.

Цагаан будаа. 19. Хоёр хуулбараас авсан ISR

Брокер 2 унаж, манлайлал 1-р брокер руу мессеж алдалгүй шилждэг. Харин одоо ISR нь зөвхөн нэг хуулбараас бүрддэг. Энэ нь бүртгэл хүлээн авах хамгийн бага тоонд тохирохгүй байгаа тул брокер бичих оролдлогод алдаатай хариу өгдөг NotEnoughReplicas.

Цагаан будаа. 20. ISR-ийн тоо min.insync.replicas-д заасан хэмжээнээс нэгээр бага байна

Энэ тохиргоо нь тууштай байхын тулд хүртээмжийг золиослодог. Мессежийг хүлээн зөвшөөрөхөөс өмнө бид үүнийг дор хаяж хоёр хуулбарт бичсэн эсэхийг баталгаажуулдаг. Энэ нь үйлдвэрлэгчдэд илүү их итгэлийг өгдөг. Энд мессежийг нэмэлт дагагч руу хуулбарлах хүртэл богино хугацаанд хоёр хуулбар нэгэн зэрэг бүтэлгүйтсэн тохиолдолд л мессеж алдагдах боломжтой бөгөөд энэ нь магадлал багатай юм. Гэхдээ хэрэв та супер гаж донтой бол хуулбарлах хүчин зүйлийг 5 болгож тохируулж болно, мөн min.insync.replicas гэхэд 3. Энд гурван брокер рекорд алдахын тулд нэгэн зэрэг унах ёстой! Мэдээжийн хэрэг, та энэ найдвартай байдлыг нэмэлт хоцролтоор төлдөг.

Мэдээллийн аюулгүй байдлын хувьд хүртээмжтэй байх шаардлагатай үед

Дотроо байдлаар RabbitMQ-тэй хэрэг, заримдаа өгөгдлийн аюулгүй байдлын хувьд хүртээмжтэй байх шаардлагатай байдаг. Та юуны талаар бодох хэрэгтэй вэ:

• Нийтлэгч зүгээр л алдаа гаргаж, дээд үйлчилгээ эсвэл хэрэглэгч дараа дахин оролдох боломжтой юу?
• Нийтлэгч мессежийг дотооддоо эсвэл мэдээллийн санд хадгалж, дараа дахин оролдох боломжтой юу?

Хэрэв хариулт нь үгүй ​​бол хүртээмжийг оновчтой болгох нь мэдээллийн аюулгүй байдлыг сайжруулдаг. Хэрэв та бичлэг хийхгүй байхын оронд боломжтой эсэхийг сонговол бага өгөгдөл алдах болно. Тиймээс бүх зүйл тэнцвэрийг олоход хүргэдэг бөгөөд шийдвэр нь тодорхой нөхцөл байдлаас хамаарна.

ISR-ийн утга

ISR иж бүрдэл нь өгөгдлийн аюулгүй байдал болон хоцрогдлын хоорондох оновчтой тэнцвэрийг сонгох боломжийг танд олгоно. Жишээлбэл, ихэнх хуулбарууд бүтэлгүйтсэн тохиолдолд бэлэн байгаа эсэхийг баталгаажуулж, хоцрогдлын хувьд үхсэн эсвэл удаан хуулбарын нөлөөллийг багасгах.

Бид утгыг өөрсдөө сонгодог replica.lag.time.max.ms таны хэрэгцээний дагуу. Үндсэндээ энэ параметр нь бид хэдийд хэр их саатал хүлээж авахыг хүсч байна гэсэн үг юм acks=бүгд. Өгөгдмөл утга нь арван секунд байна. Хэрэв энэ нь танд хэтэрхий урт байвал та үүнийг багасгаж болно. Дараа нь дагагчдыг устгаж, илүү олон удаа нэмэх тул ISR-ийн өөрчлөлтийн давтамж нэмэгдэх болно.

RabbitMQ бол зүгээр л хуулбарлах шаардлагатай тольны багц юм. Удаан толин тусгал нь нэмэлт хоцролтыг бий болгодог бөгөөд үхсэн толин тусгал нь зангилаа бүрийн бэлэн байдлыг шалгадаг пакетууд (цэвэр тэмдэглэгээ) хариу өгөх хүртэл хүлээх боломжтой. ISR нь эдгээр хоцрогдлын асуудлаас зайлсхийх сонирхолтой арга юм. Гэхдээ ISR нь зөвхөн удирдагч руу багасах боломжтой тул бид цомхотголоо алдах эрсдэлтэй. Энэ эрсдэлээс зайлсхийхийн тулд тохиргоог ашиглана уу min.insync.replicas.

Үйлчлүүлэгчийн холболтын баталгаа

Тохиргоо дээр bootstrap.servers Үйлдвэрлэгч болон хэрэглэгч үйлчлүүлэгчдийг холбох олон брокеруудыг зааж өгч болно. Гол санаа нь нэг зангилаа тасрахад үйлчлүүлэгч холболт нээх боломжтой хэд хэдэн нөөц үлдсэн болно. Эдгээр нь заавал хэсгийн ахлагч биш, харин зүгээр л эхний ачааллын трамплин юм. Үйлчлүүлэгч тэднээс унших/бичих хуваалтын удирдагчийг аль зангилаа байршуулахыг асууж болно.

RabbitMQ-д үйлчлүүлэгчид дурын зангилаа руу холбогдох боломжтой бөгөөд дотоод чиглүүлэлт нь хүсэлтийг шаардлагатай газар руу илгээдэг. Энэ нь та RabbitMQ-ийн өмнө ачаалал тэнцвэржүүлэгчийг суулгаж болно гэсэн үг юм. Кафка үйлчлүүлэгчдээс харгалзах хуваалтын удирдагчийг байрлуулсан зангилаа руу холбогдохыг шаарддаг. Ийм нөхцөлд та ачаалал тэнцвэржүүлэгчийг суулгаж чадахгүй. Жагсаалт bootstrap.servers Үйлчлүүлэгчид алдаа гарсны дараа зөв зангилаа руу хандаж, олох боломжтой байх нь чухал юм.

Кафка консенсус архитектур

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

Кафка кластер бүрийг Zookeeper кластерын хамт байрлуулсан бөгөөд энэ нь системд тодорхой төлөв байдлын талаар зөвшилцөлд хүрэх боломжийг олгодог, хүртээмжтэй байхаас илүү тогтвортой байдлыг чухалчилдаг. Унших, бичих үйлдлийг зөвшөөрөхийн тулд амьтны хүрээлэнгийн ихэнх зангилааны зөвшөөрөл шаардлагатай.

Амьтны хамгаалагч нь кластерын төлөвийг хадгалдаг:

• Сэдвийн жагсаалт, хэсэг, тохиргоо, одоогийн удирдагч хуулбар, илүүд үзсэн хуулбар.
• Кластерийн гишүүд. Брокер бүр Zookeeper кластерт пинг хийдэг. Хэрэв заасан хугацаанд пинг хүлээн авахгүй бол Zookeeper брокерыг боломжгүй гэж тэмдэглэнэ.
• Хянагчийн үндсэн болон сэлбэг зангилааг сонгох.

Хянагч зангилаа нь хуулбар удирдагчдыг сонгох үүрэгтэй Кафка брокеруудын нэг юм. Амьтны хамгаалагч нь кластерын гишүүнчлэл болон сэдвийн өөрчлөлтийн талаар хянагч руу мэдэгдэл илгээдэг бөгөөд хянагч эдгээр өөрчлөлтийн дагуу ажиллах ёстой.

Жишээлбэл, арван хуваалттай шинэ сэдвийг авч үзье, хуулбарлах хүчин зүйл нь 3. Удирдагч нь хуваалт бүрт удирдагч сонгох ёстой бөгөөд брокеруудын дунд удирдагчдыг оновчтой хуваарилахыг хичээдэг.

Хэсэг хянагч бүрийн хувьд:

• ISR болон удирдагчийн тухай Zookeeper дахь мэдээллийг шинэчилдэг;
• Энэ хуваалтын хуулбарыг байршуулсан брокер бүрт LeaderAndISRCommand илгээж, ISR болон удирдагчийн талаар брокеруудад мэдээлдэг.

Удирдагчтай брокер унах үед амьтны хүрээлэнгийн ажилтан хянагч руу мэдэгдэл илгээж, шинэ удирдагчийг сонгодог. Дахин хэлэхэд, хянагч эхлээд Zookeeper-ийг шинэчилж, дараа нь брокер бүрд удирдлагын өөрчлөлтийн талаар мэдэгдэх тушаал илгээдэг.

Удирдагч бүр ISR-ийг элсүүлэх үүрэгтэй. Тохиргоо replica.lag.time.max.ms Тэнд хэн орохыг тодорхойлно. ISR өөрчлөгдөхөд удирдагч шинэ мэдээллийг амьтны хүрээлэнгийн ажилтанд дамжуулдаг.

Амьтны хүрээлэнгийн ажилтанд аливаа өөрчлөлтийн талаар байнга мэдэгддэг бөгөөд ингэснээр бүтэлгүйтсэн тохиолдолд удирдлага шинэ удирдагч руу жигд шилждэг.

Цагаан будаа. 21. Кафка зөвшилцөл

Хуулбарлах протокол

Хуулбарлах нарийн ширийнийг ойлгох нь өгөгдөл алдагдах нөхцөл байдлыг илүү сайн ойлгоход тусална.

Түүврийн асуулга, Бүртгэлийн төгсгөлийн зөрүү (LEO) болон Өндөр усны тэмдэг (HW)

Дагагчид үе үе удирдагч руу дуудах хүсэлт илгээдэг гэж бид үзсэн. Өгөгдмөл интервал нь 500 мс байна. Энэ нь RabbitMQ-ээс ялгаатай нь RabbitMQ-д хуулбарлах үйлдлийг дарааллын толин тусгал биш, харин мастер эхлүүлдэг. Мастер өөрчлөлтийг толин тусгал руу түлхдэг.

Удирдагч болон бүх дагалдагчид Log End Offset (LEO) болон Highwater (HW) шошгыг хадгалдаг. LEO тэмдэг нь орон нутгийн хуулбар дахь сүүлчийн мессежийн офсетийг хадгалдаг бөгөөд HW нь сүүлчийн амлалтын офсетийг хадгалдаг. Үйлдлийн төлөвийн хувьд мессеж нь бүх ISR хуулбар дээр хадгалагдах ёстой гэдгийг санаарай. Энэ нь LEO ихэвчлэн HW-ээс бага зэрэг түрүүлдэг гэсэн үг юм.

Удирдагч мессеж хүлээн авахдаа түүнийгээ дотооддоо хадгалдаг. Дагагч нь өөрийн LEO-г дамжуулж дуудах хүсэлт гаргадаг. Дараа нь удирдагч энэ LEO-ээс эхлэн багц мессеж илгээж, мөн одоогийн HW-г дамжуулдаг. Удирдагч бүх хуулбарууд мессежийг өгөгдсөн офсет дээр хадгалсан гэсэн мэдээллийг хүлээн авах үед энэ нь HW тэмдгийг хөдөлгөдөг. Зөвхөн удирдагч нь HW-г хөдөлгөж чадах тул бүх дагалдагчид өөрсдийн хүсэлтийн хариуд одоогийн үнэ цэнийг мэдэх болно. Энэ нь дагалдагчид мессеж болон HW мэдлэгийн хувьд удирдагчаас хоцорч болно гэсэн үг юм. Хэрэглэгчид зөвхөн одоогийн HW хүртэл мессеж хүлээн авдаг.

"Тогтвортой" гэдэг нь диск рүү биш санах ойд бичигдсэн гэсэн үг гэдгийг анхаарна уу. Гүйцэтгэлийн хувьд Кафка тодорхой интервалаар диск рүү синхрончлогддог. RabbitMQ бас ийм интервалтай боловч мастер болон бүх толин тусгалууд диск рүү мессеж бичсэний дараа л нийтлэгчид хүлээн зөвшөөрлийг илгээх болно. Кафкагийн хөгжүүлэгчид гүйцэтгэлийн шалтгаанаар мессежийг санах ойд бичсэн даруйд нь акк илгээхээр шийджээ. Илүүдэл нь хүлээн зөвшөөрөгдсөн мессежийг зөвхөн санах ойд богино хугацаанд хадгалах эрсдэлийг нөхнө гэж Кафка мөрийцдөг.

Удирдагчийн бүтэлгүйтэл

Удирдагч унах үед амьтны хүрээлэнгийн ажилтан хянагчдаа мэдэгдэн шинэ удирдагчийн хуулбарыг сонгоно. Шинэ удирдагч өөрийн LEO-ийн дагуу шинэ HW тэмдгийг тогтоодог. Дараа нь дагагчид шинэ удирдагчийн тухай мэдээлэл авдаг. Кафкагийн хувилбараас хамааран дагагч хоёр хувилбараас аль нэгийг нь сонгоно.

1. Энэ нь мэдэгдэж буй HW-д орон нутгийн бүртгэлийг тайрч, энэ тэмдгийн дараа мессеж авах хүсэлтийг шинэ удирдагч руу илгээнэ.
2. Удирдагчаар сонгогдсон үеийн HW-ийг олж мэдэх хүсэлтийг удирдагч руу илгээж, дараа нь энэ офсет руу логыг тайруулна. Дараа нь энэ офсетээс эхлэн үе үе дуудах хүсэлт гаргаж эхэлнэ.

Дараах шалтгааны улмаас дагагч логийг хасах шаардлагатай байж магадгүй.

• Удирдагч амжилтгүй болсон тохиолдолд Zookeeper-д бүртгүүлсэн ISR багцын эхний дагагч сонгуульд ялж, тэргүүлэгч болно. ISR дээрх бүх дагалдагчид хэдийгээр "синхрончлогдсон" гэж тооцогддог ч өмнөх удирдагчаас ирсэн бүх мессежийн хуулбарыг хүлээн аваагүй байж магадгүй юм. Онцолсон дагагч нь хамгийн сүүлийн үеийн хуулбаргүй байх бүрэн боломжтой. Кафка хуулбаруудын хооронд ямар ч ялгаа байхгүй гэдгийг баталгаажуулдаг. Тиймээс, зөрүү гарахаас зайлсхийхийн тулд дагагч бүр өөрийн бүртгэлээ шинэ удирдагчийн сонгогдох үеийн HW үнэ цэнээр бууруулах ёстой. Энэ нь тохируулах өөр нэг шалтгаан юм acks=бүгд тууштай байх нь маш чухал.
• Мессежийг үе үе диск рүү бичдэг. Хэрэв бүх кластерийн зангилаанууд нэгэн зэрэг бүтэлгүйтвэл өөр өөр офсет бүхий хуулбарууд диск дээр хадгалагдах болно. Брокерууд онлайнаар буцаж ирэхэд сонгогдсон шинэ удирдагч бусдаасаа өмнө дискэнд хадгалагдсан тул дагалдагчдынхаа ард байх магадлалтай.

Кластертай дахин нэгдэх

Кластерт дахин нэгдэх үед хуулбарууд нь удирдагч амжилтгүй болсонтой адил үйлдлүүдийг хийдэг: тэд удирдагчийн хуулбарыг шалгаж, бүртгэлээ HW (сонгуулийн үеэр) руу тайрдаг. Харьцуулбал, RabbitMQ нь дахин нийлсэн зангилааг цоо шинэ гэж адилхан үздэг. Аль ч тохиолдолд брокер одоо байгаа бүх төлөвийг устгадаг. Хэрэв автомат синхрончлолыг ашигладаг бол мастер нь "бүх дэлхийг хүлээх" аргын дагуу шинэ толин тусгал руу одоогийн бүх агуулгыг хуулбарлах ёстой. Мастер энэ үйлдлийн явцад унших, бичих ямар ч үйлдлийг хүлээн авахгүй. Энэ арга нь том дараалалд асуудал үүсгэдэг.

Кафка бол тархсан бүртгэл бөгөөд ерөнхийдөө энэ нь RabbitMQ дарааллаас илүү олон мессежийг хадгалдаг бөгөөд өгөгдлийг уншсаны дараа дарааллаас хасдаг. Идэвхтэй дараалал харьцангуй бага хэвээр байх ёстой. Гэхдээ Кафка бол өдөр, долоо хоногийн хугацааг тогтоож болох өөрийн гэсэн хадгалах бодлоготой гуалин юм. Дараалалыг хаах, бүрэн синхрончлох арга нь тархсан бүртгэлийн хувьд огт хүлээн зөвшөөрөгдөхгүй. Харин Кафкагийн дагалдагчид, хэрэв тэдний хуулбар удирдагчаас түрүүлж байвал удирдагчийн HW-д (түүний сонгогдох үед) бүртгэлээ тайруулдаг. Илүү магадлалтай тохиолдолд, дагагч нь хоцрогдсон үед одоогийн LEO-оосоо эхлэн дуудах хүсэлтийг гаргаж эхэлдэг.

Шинэ эсвэл дахин нэгдсэн дагалдагчид ISR-ээс гадуур эхэлдэг бөгөөд үүрэг хариуцлагад оролцдоггүй. Тэд зүгээр л бүлгийнхэнтэй зэрэгцэн ажиллаж, удирдагчийг гүйцэж, ISR-д орох хүртлээ мессежийг аль болох хурдан хүлээн авдаг. Ямар ч түгжээ байхгүй бөгөөд таны бүх өгөгдлийг хаях шаардлагагүй.

Холболтын алдагдал

Кафка нь RabbitMQ-аас илүү олон бүрэлдэхүүн хэсгүүдтэй тул кластер салгагдах үед илүү төвөгтэй зан үйлийн багцтай байдаг. Гэхдээ Кафка анх кластерт зориулагдсан тул шийдлүүдийг маш сайн бодож боловсруулсан.

Холболтын эвдрэлийн хэд хэдэн хувилбаруудыг доор харуулав:

• Хувилбар 1: Дагагч нь удирдагчийг хардаггүй ч амьтны хүрээлэнгийн эрхлэгчийг хардаг.
• Хувилбар 2: Удирдагч ямар ч дагагчийг хардаггүй ч амьтны хүрээлэнгийн ажилтантай уулздаг.
• Хувилбар 3: Дагагч нь удирдагчийг хардаг боловч амьтны хүрээлэнгийн эрхлэгчийг хардаггүй.
• Хувилбар 4: Удирдагч дагалдагчдыг хардаг боловч амьтны хүрээлэнгийн эрхлэгчийг хардаггүй.
• Хувилбар 5: Дагагч нь бусад Кафка зангилаа болон Zookeeper-ээс бүрэн тусдаа байна.
• Хувилбар 6: Удирдагч нь бусад Кафка зангилаа болон амьтны хүрээлэнгээс бүрэн тусдаа байдаг.
• Хувилбар 7: Кафка хянагчийн зангилаа өөр Кафка зангилаа харж чадахгүй байна.
• Хувилбар 8: Кафка хянагч Zookeeper-г харахгүй байна.

Сценари бүр өөрийн гэсэн зан чанартай байдаг.

Хувилбар 1: Дагагч удирдагчийг хардаггүй ч амьтны хүрээлэнгийн ажилтанг харсаар байна

Цагаан будаа. 22. Хувилбар 1: Гурван хуулбарын ISR

Холболтын доголдол нь брокер 3-ыг 1 ба 2-р брокеруудаас тусгаарладаг боловч Zookeeper-ээс биш. Брокер 3 цаашид дуудах хүсэлт илгээх боломжгүй. Цаг хугацаа өнгөрсний дараа replica.lag.time.max.ms Энэ нь ISR-ээс хасагдсан бөгөөд мессеж хүлээн авахад оролцдоггүй. Холболт сэргэсний дараа энэ нь дуудах хүсэлтийг үргэлжлүүлж, удирдагчийг гүйцэх үед ISR-д нэгдэнэ. Амьтны хүрээлэнгийн ажилтан пинг хүлээн авсаар байх бөгөөд брокер амьд, сайн байгаа гэж таамаглах болно.

Цагаан будаа. 23. Хувилбар 1: Хэрэв replica.lag.time.max.ms интервалын дотор зуучлах хүсэлт ирээгүй бол брокерийг ISR-ээс хасна.

RabbitMQ шиг хуваагдмал тархи эсвэл зангилааны түдгэлзүүлэлт байхгүй. Үүний оронд илүүдэл багассан.

Хувилбар 2: Удирдагч ямар ч дагагчийг хардаггүй ч амьтны хүрээлэнгийн ажилтантай уулздаг

Цагаан будаа. 24. Хувилбар 2. Удирдагч ба хоёр дагагч

Сүлжээний холболтын эвдрэл нь удирдагчийг дагалдагчдаас тусгаарладаг боловч брокер Zookeeper-ийг харах боломжтой хэвээр байна. Эхний хувилбарын адил ISR багасч, гэхдээ энэ удаад бүх дагалдагчид дуудах хүсэлт илгээхээ больсон тул зөвхөн удирдагчид л очно. Дахин хэлэхэд логик хуваагдал байхгүй. Үүний оронд холболт сэргээгдэх хүртэл шинэ мессежийн нөөц алдагдах болно. Амьтны хүрээлэнгийн ажилтан пинг хүлээн авсаар байгаа бөгөөд брокер амьд, сайн байгаа гэдэгт итгэж байна.

Цагаан будаа. 25. Хувилбар 2. ISR нь зөвхөн удирдагч руу багассан

Хувилбар 3. Дагагч нь удирдагчийг хардаг боловч амьтны хүрээлэнгийн эрхлэгчийг хардаггүй

Дагагч нь Zookeeper-ээс тусгаарлагдсан боловч удирдагчтай брокероос тусгаарлагддаггүй. Үүний үр дүнд дагагч нь дуудах хүсэлтийг үргэлжлүүлэн гаргаж, ISR-ийн гишүүн байх болно. Zookeeper нь пинг хүлээн авахаа больж, брокерын эвдрэлийг бүртгэхээ больсон, гэхдээ энэ нь зөвхөн дагагч учраас эдгэрсний дараа ямар ч үр дагавар гарахгүй.

Цагаан будаа. 26. Хувилбар 3: Дагагч нь ахлагч руу дуудах хүсэлт илгээсээр байна

Хувилбар 4. Удирдагч дагагчдыг хардаг боловч амьтны хүрээлэнгийн ажилтанг хардаггүй

Цагаан будаа. 27. Хувилбар 4. Удирдагч ба хоёр дагагч

Удирдагч нь амьтны хүрээлэнгээс тусгаарлагдсан боловч дагалдагчтай брокеруудаас биш юм.

Цагаан будаа. 28. Хувилбар 4: Удирдагч амьтны хүрээлэнгээс тусгаарлагдсан

Хэсэг хугацааны дараа Zookeeper брокерын алдааг бүртгэж, хянагчдаа мэдэгдэнэ. Тэрээр дагалдагчдынхаа дундаас шинэ удирдагч сонгох болно. Гэсэн хэдий ч анхны удирдагч нь тэргүүлэгч гэж бодсоор ирсэн бөгөөд ирүүлсэн материалыг хүлээн авах болно acks=1. Дагагчид түүнд дуудах хүсэлт илгээхээ больсон тул тэр тэднийг үхсэн гэж үзэж, ISR-ийг өөртөө багасгахыг хичээх болно. Гэхдээ энэ нь Zookeeper-тэй холбоогүй тул үүнийг хийх боломжгүй бөгөөд тэр үед нэмэлт оруулгуудыг хүлээн авахаас татгалзах болно.

Мессежүүд acks=бүгд ISR эхлээд бүх хуулбарыг асааж, мессеж тэдэнд хүрэхгүй тул хүлээн зөвшөөрөхгүй. Анхны удирдагч тэднийг ISR-ээс хасах гэж оролдох үед тэр үүнийг хийх боломжгүй бөгөөд ямар ч мессеж хүлээн авахаа болино.

Үйлчлүүлэгчид удирдагчийн өөрчлөлтийг удалгүй анзаарч, шинэ сервер рүү бичлэг илгээж эхэлдэг. Сүлжээг сэргээсний дараа анхны удирдагч нь тэргүүлэгч байхаа больсоныг хараад бүртгэлийн зөрүүгээс зайлсхийхийн тулд шинэ удирдагчийн амжилтгүй болсон үеийн HW утга руу логоо тайруулна. Дараа нь шинэ удирдагч руу дуудах хүсэлтийг илгээж эхэлнэ. Анхны удирдагчаас шинэ удирдагч хүртэл хуулбарлаагүй бүх бүртгэл алдагдсан. Өөрөөр хэлбэл, хоёр удирдагч ажиллаж байсан хэдхэн секундын дотор анхны удирдагч хүлээн зөвшөөрөөгүй мессежүүд алга болно.

Цагаан будаа. 29. Хувилбар 4. Сүлжээг сэргээсний дараа 1-р брокер дээрх удирдагч дагагч болно.

Хувилбар 5: Дагагч нь бусад Кафка зангилаа болон Zookeeper-ээс бүрэн тусдаа байна

Дагагч нь бусад Кафка зангилаа болон Zookeeper-ээс бүрэн тусгаарлагдсан. Сүлжээг сэргээх хүртэл тэр зүгээр л өөрийгөө ISR-ээс салгаж, дараа нь бусдыг гүйцэх болно.

Цагаан будаа. 30. Хувилбар 5: Тусгаарлагдсан дагагчийг ISR-ээс хассан

Хувилбар 6: Удирдагч нь бусад Кафка зангилаа болон амьтны хүрээлэнгээс бүрэн тусдаа байдаг

Цагаан будаа. 31. Хувилбар 6. Удирдагч ба хоёр дагагч

Удирдагч нь дагагчид болох хянагч, амьтны хүрээлэнгээс бүрэн тусгаарлагдсан байдаг. Богино хугацаанд энэ нь бүртгэлийг үргэлжлүүлэн хүлээн авах болно acks=1.

Цагаан будаа. 32. Хувилбар 6: Удирдагчийг бусад Кафка болон амьтны хүрээлэнгийн зангилаанаас тусгаарлах

Хугацаа дууссаны дараа хүсэлт хүлээн аваагүй replica.lag.time.max.ms, энэ нь ISR-ийг өөртөө багасгахыг оролдох боловч Zookeeper-тэй ямар ч холбоо байхгүй тул үүнийг хийх боломжгүй, дараа нь бичвэр хүлээн авахаа болино.

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

Цагаан будаа. 33. Хувилбар 6. Хоёр удирдагч

Анхны удирдагч хэдхэн секундын турш оруулгуудыг хүлээж авах боловч дараа нь ямар ч мессежийг хүлээн авахаа болино. Үйлчлүүлэгчид 60 секунд тутамд хамгийн сүүлийн үеийн мета өгөгдлөөр шинэчлэгддэг. Тэд удирдагчийн өөрчлөлтийн талаар мэдээлэх бөгөөд шинэ удирдагч руу бүртгэл илгээж эхэлнэ.

Цагаан будаа. 34. Хувилбар 6: Үйлдвэрлэгчид шинэ удирдагч руу шилждэг

Холболт алдагдсанаас хойш анхны удирдагчийн хийсэн баталгаажуулсан бүх оруулгууд устах болно. Сүлжээг сэргээсний дараа анхны удирдагч Zookeeper-ээр дамжуулан ахлагч байхаа больсон гэдгийг олж мэдэх болно. Дараа нь сонгуулийн үеэр шинэ удирдагчийн HW руу бүртгэлээ тайрч, дагалдагчаар хүсэлт илгээж эхэлнэ.

Цагаан будаа. 35. Хувилбар 6: Сүлжээний холболт сэргэсний дараа анхны удирдагч дагагч болно

Энэ тохиолдолд логик тусгаарлалт богино хугацаанд тохиолдож болно, гэхдээ зөвхөн ийм тохиолдолд acks=1 и min.insync.replicas мөн 1. Сүлжээг сэргээсний дараа, анхны удирдагч өөрийгөө ахлагч байхаа больсоноо мэдээд, эсвэл бүх үйлчлүүлэгчид удирдагч өөрчлөгдсөнийг мэдээд шинэ удирдагч руу захидал бичиж эхлэх үед аль нь түрүүлж байвал логик тусгаарлалт автоматаар дуусна. Ямар ч тохиолдолд зарим мессеж алга болно, гэхдээ зөвхөн acks=1.

Сүлжээ хуваагдахаас өмнөхөн дагалдагчид хоцорч, удирдагч нь ISR-ийг зөвхөн өөртөө шахаж байсан энэ хувилбарын өөр нэг хувилбар бий. Дараа нь холболт тасарсан тул тусгаарлагдана. Шинэ удирдагч сонгогдсон ч анхны удирдагч нь элсэлтээ хүлээн авсаар байна acks=бүгд, учир нь ISR-д түүнээс өөр хэн ч байхгүй. Сүлжээг сэргээсний дараа эдгээр бүртгэл устах болно. Энэ сонголтоос зайлсхийх цорын ганц арга зам юм min.insync.replicas = 2.

Хувилбар 7: Кафка хянагч зангилаа өөр Кафка зангилаа харж чадахгүй байна

Ерөнхийдөө Кафка зангилаатай холболт тасарсан тохиолдолд хянагч түүнд удирдагчийн өөрчлөлтийн мэдээллийг дамжуулах боломжгүй болно. Хамгийн муу тохиолдолд энэ нь 6-р хувилбарын адил богино хугацааны логик салалтад хүргэнэ. Ихэнх тохиолдолд брокер нь амжилтгүй болсон тохиолдолд манлайллын нэр дэвшигч болж чадахгүй.

Хувилбар 8: Кафка хянагч Zookeeper-г харахгүй байна

Амьтны хүрээлэнгийн ажилтан унасан хянагчаас пинг хүлээн авахгүй бөгөөд шинэ Кафка зангилааг хянагчаар сонгоно. Анхны хянагч нь өөрийгөө үргэлжлүүлэн харуулах боломжтой боловч Zookeeper-ээс мэдэгдэл хүлээн авдаггүй тул түүнд хийх ажил байхгүй болно. Сүлжээг сэргээсний дараа тэрээр хянагч байхаа больж, ердийн Кафка зангилаа болсон гэдгээ ойлгох болно.

Сценариас хийсэн дүгнэлт

Дагагчийн холболт алдагдах нь мессеж алдагдахад хүргэдэггүй, харин сүлжээг сэргээх хүртэл илүүдэл тоог түр зуур бууруулдаг гэдгийг бид харж байна. Энэ нь мэдээжийн хэрэг нэг буюу хэд хэдэн зангилаа алдагдсан тохиолдолд өгөгдлийн алдагдалд хүргэж болзошгүй юм.

Хэрэв ахлагч холболт тасарсны улмаас амьтны хүрээлэнгээс салсан бол энэ нь дараахаас мессеж алдагдаж болзошгүй. acks=1. Амьтны хүрээлэнгийн ажилтантай харилцаа холбоогүй байгаа нь хоёр удирдагчтай товч логик хуваагдал үүсгэдэг. Энэ асуудлыг параметрээр шийддэг acks=бүгд.

Үзүүлэлт min.insync.replicas Хоёр ба түүнээс дээш хуулбар хийх нь ийм богино хугацааны хувилбарууд нь Хувилбар 6 дахь шиг мессежийг алдахад хүргэхгүй гэсэн нэмэлт баталгааг өгдөг.

Алдагдсан мессежүүдийн хураангуй

Кафка дахь өгөгдлийг алдаж болох бүх аргуудыг жагсаая:

• Хэрэв мессежийг ашиглан баталгаажуулсан бол удирдагчийн бүтэлгүйтэл acks=1
• Удирдлагын аливаа бузар шилжилт, өөрөөр хэлбэл, ISR-ээс гадуур дагалдагч руу, тэр ч байтугай хамт acks=бүгд
• Зурвасуудыг ашиглан баталгаажуулсан бол удирдагчийг амьтны хүрээлэнгээс тусгаарлана acks=1
• ISR бүлгийг аль хэдийн өөрт нь багасгасан удирдагчийг бүрэн тусгаарлах. Бүх мессежүүд алга болно, тэр ч байтугай acks=бүгд. Хэрэв энэ нь зөвхөн үнэн юм min.insync.replicas=1.
• Бүх хуваалтын зангилааны нэгэн зэрэг эвдрэл. Мессежүүд нь санах ойноос хүлээн зөвшөөрөгдсөн байдаг тул заримыг нь дискэнд бичээгүй байж болно. Серверүүдийг дахин ачаалсны дараа зарим мессеж дутуу байж магадгүй.

Удирдлагын цэвэр бус шилжилтийг хориглох эсвэл дор хаяж хоёр орон тооны цомхотгол хийх замаар зайлсхийх боломжтой. Хамгийн бат бөх тохиргоо нь хослол юм acks=бүгд и min.insync.replicas 1-ээс их.

RabbitMQ болон Кафкагийн найдвартай байдлын шууд харьцуулалт

Найдвартай байдал, өндөр хүртээмжийг хангахын тулд хоёр платформ нь үндсэн болон хоёрдогч хуулбарлах системийг хэрэгжүүлдэг. Гэсэн хэдий ч RabbitMQ нь Achilles өсгийтэй. Алдаа гарсны дараа дахин холбогдох үед зангилаанууд өгөгдлөө хаяж, синхрончлолыг хаадаг. Энэхүү давхар зовиур нь RabbitMQ дахь том дарааллын урт наслалтад эргэлзээ төрүүлж байна. Та цомхотгол эсвэл урт блоклох хугацааг хүлээн зөвшөөрөх хэрэгтэй болно. Илүүдэл тоог багасгах нь их хэмжээний мэдээлэл алдах эрсдэлийг нэмэгдүүлдэг. Гэхдээ хэрвээ дараалал нь жижиг бол илүүдлийг арилгахын тулд богино хугацаанд (хэдхэн секунд) ашиглах боломжгүй бол давтан холболт хийх оролдлогыг ашиглан шийдэж болно.

Кафкад ийм асуудал байхгүй. Энэ нь зөвхөн удирдагч болон дагагч хоёрын зөрүүтэй цэгээс өгөгдлийг устгадаг. Бүх хуваалцсан өгөгдөл хадгалагдсан. Үүнээс гадна хуулбарлах нь системийг блоклодоггүй. Удирдагч нь шинэ дагагчийг гүйцэж байх хооронд бичлэгүүдийг хүлээн авсаар байдаг тул devops-ийн хувьд кластерт нэгдэх эсвэл дахин нэгдэх нь энгийн ажил болдог. Мэдээжийн хэрэг, хуулбарлах явцад сүлжээний зурвасын өргөн гэх мэт асуудлууд байсаар байна. Хэрэв та олон дагагчийг нэгэн зэрэг нэмбэл зурвасын өргөний хязгаарлалттай тулгарах болно.

RabbitMQ нь кластер дахь олон серверүүд зэрэг доголдох үед найдвартай байдлын хувьд Кафкагаас илүү байдаг. Өмнө дурьдсанчлан, RabbitMQ нь мессежийг мастер болон бүх толин тусгалууд дээр дискэнд бичсэний дараа л нийтлэгчид баталгаажуулалтыг илгээдэг. Гэхдээ энэ нь хоёр шалтгааны улмаас нэмэлт хоцрогдол үүсгэдэг:

• fsync хэдэн зуун миллисекунд тутамд
• Толин тусгалын эвдрэлийг зангилаа бүрийн бэлэн байдлыг шалгадаг пакетуудын ашиглалтын хугацаа дууссаны дараа л анзаарч болно. Хэрэв толин тусгал удааширч эсвэл унах юм бол энэ нь саатал нэмнэ.

Кафкагийн бооцоо бол хэрэв мессеж олон цэг дээр хадгалагдсан бол санах ойд хүрсэн даруйдаа мессежийг хүлээн зөвшөөрч чадна гэж бооцоо тавьсан. Үүнээс болж ямар ч төрлийн мессеж алдагдах эрсдэлтэй (тэр ч байтугай acks=бүгд, min.insync.replicas=2) нэгэн зэрэг эвдэрсэн тохиолдолд.

Ерөнхийдөө Кафка нь програм хангамжийн гүйцэтгэлийг илүү сайн харуулсан бөгөөд кластеруудад зориулж анхнаасаа бүтээгдсэн. Найдвартай байхын тулд шаардлагатай бол дагагчдын тоог 11 хүртэл нэмэгдүүлэх боломжтой. Хуулбарлах хүчин зүйл 5 ба синхрончлол дахь хуулбарын хамгийн бага тоо min.insync.replicas=3 мессеж алдах нь маш ховор тохиолдох болно. Хэрэв таны дэд бүтэц энэ хуулбарын харьцаа болон нөөцийн түвшинг дэмжиж чадвал та энэ сонголтыг сонгож болно.

RabbitMQ кластер нь жижиг дараалалд тохиромжтой. Гэхдээ ачаалал ихтэй үед жижиг дараалал ч хурдан өсдөг. Дараалал томорсны дараа та бэлэн байдал, найдвартай байдлын хооронд хатуу сонголт хийх хэрэгтэй болно. RabbitMQ кластер нь RabbitMQ-ийн уян хатан байдлын ашиг тус нь кластерын сул талуудаас илүү байдаг ердийн бус нөхцөлд хамгийн тохиромжтой.

RabbitMQ-ийн том дараалалд өртөх эмзэг байдлыг арилгах нэг арга бол тэдгээрийг олон жижиг дараалал болгон хуваах явдал юм. Хэрэв та бүх дарааллыг бүрэн захиалах шаардлагагүй, харин зөвхөн холбогдох мессежүүд (жишээлбэл, тодорхой үйлчлүүлэгчийн мессежүүд) эсвэл юу ч захиалахгүй бол энэ сонголтыг зөвшөөрнө: миний төслийг харна уу. Дахин тэнцвэржүүлэгч дарааллыг хуваах (төсөл эхний шатандаа байна).

Эцэст нь, RabbitMQ болон Кафка хоёрын кластер, хуулбарлах механизмын хэд хэдэн алдааны талаар бүү мартаарай. Цаг хугацаа өнгөрөх тусам системүүд илүү боловсорч, тогтвортой болсон ч ямар ч мессеж алдагдахаас 100% аюулгүй байх болно! Үүнээс гадна дата төвүүдэд томоохон хэмжээний осол гардаг!

Хэрэв би ямар нэг зүйлийг орхигдуулсан, алдаа гаргасан эсвэл аль нэг зүйлтэй санал нийлэхгүй байгаа бол сэтгэгдэл бичих эсвэл надтай холбоо бариарай.

Надаас "Юу сонгох вэ, Кафка эсвэл RabbitMQ?", "Аль платформ илүү дээр вэ?" гэж байнга асуудаг. Үнэн бол энэ нь таны нөхцөл байдал, одоогийн туршлага гэх мэтээс шалтгаална. Би өөрийн санал бодлоо илэрхийлэхдээ эргэлзэж байна, учир нь нэг платформыг ашиглах бүх тохиолдлууд болон боломжит хязгаарлалтуудад санал болгох нь хэтэрхий хялбарчлах болно. Та өөрийн үзэл бодлыг бий болгохын тулд би энэ цуврал нийтлэлийг бичсэн.

Хоёр систем хоёулаа энэ салбарт тэргүүлэгч гэдгийг хэлмээр байна. Төслийн туршлагаасаа би баталгаатай мессежийн захиалга, найдвартай байдал гэх мэт зүйлсийг үнэлдэг тул би бага зэрэг өрөөсгөл байж магадгүй юм.

Би ийм найдвартай байдал, баталгаатай захиалга байхгүй бусад технологиудыг хараад RabbitMQ, Kafka-г хараад эдгээр хоёр системийн гайхалтай үнэ цэнийг ойлгодог.

Эх сурвалж: www.habr.com