د غلطۍ زغم او لوړ شتون لوی موضوعات دي، نو موږ به RabbitMQ او Kafka ته جلا مقالې وقف کړو. دا مقاله د RabbitMQ په اړه ده، او بله بله د RabbitMQ په پرتله د کافکا په اړه ده. دا یوه اوږده مقاله ده، نو خپل ځان آرام کړئ.

راځئ چې د خطا زغم، دوام، او د لوړ شتون (HA) ستراتیژیو او سوداګریزو کړنو ته وګورو چې هره ستراتیژي جوړوي. RabbitMQ کولی شي د نوډونو په کلستر کې پرمخ بوځي - او بیا د توزیع شوي سیسټم په توګه طبقه بندي کیږي. کله چې د توزیع شوي سیسټمونو خبره راځي، موږ ډیری وختونه د دوام او شتون په اړه خبرې کوو.

دا مفکورې تشریح کوي چې سیسټم څنګه چلند کوي کله چې دا ناکام شي. د شبکې اتصال ناکامي، د سرور ناکامي، د هارډ ډرایو ناکامي، د سرور لنډمهاله نه شتون د کثافاتو راټولولو، د بسته بندۍ له امله، یا د شبکې اتصال سستوالی. دا ټول کولی شي د معلوماتو له لاسه ورکولو یا شخړو لامل شي. دا معلومه شوه چې دا واقعیا ناممکن ده چې یو داسې سیسټم رامینځته کړئ چې دواړه په بشپړ ډول مطابقت ولري (د ډیټا ضایع نه وي ، هیڅ ډیټا توپیر نلري) او د ټولو ناکامیو سناریوګانو لپاره شتون لري (لوستل او لیکل به ومني).

موږ به وګورو چې دوام او شتون د سپیکٹرم په مخالفو سرونو کې دی، او تاسو اړتیا لرئ چې د اصلاح کولو لپاره کومه لاره غوره کړئ. ښه خبر دا دی چې د RabbitMQ سره دا انتخاب ممکن دی. تاسو دا ډول "نرډي" لیورونه لرئ ترڅو توازن د ډیر دوام یا لوی لاسرسي په لور واړوئ.

موږ به ځانګړې پاملرنه وکړو چې کوم تشکیلات د تایید شوي ریکارډونو له امله د معلوماتو ضایع کیدو لامل کیږي. د خپرونکو، بروکرانو او مصرف کونکو ترمنځ د مسؤلیت سلسله شتون لري. یوځل چې پیغام بروکر ته لیږدول کیږي، دا د هغه دنده ده چې پیغام له لاسه ورنکړي. کله چې بروکر د خپرونکي پیغام ترلاسه کول مني، موږ تمه نه لرو چې دا له لاسه ورکړي. مګر موږ به وګورو چې دا واقعیا ستاسو د بروکر او خپرونکي تشکیلاتو پورې اړه لري.

د واحد نوډ مقاومت لومړني

مقاومت لرونکی قطار/روټینګ

په RabbitMQ کې دوه ډوله کتارونه شتون لري: دوامدار او غیر دوامدار. ټول کتارونه د مینیسیا ډیټابیس کې خوندي شوي. دوامداره کتارونه د نوډ په پیل کې بیا اعلان کیږي او پدې توګه د بیا پیل کیدو ، د سیسټم خرابیدو ، یا د سرور کریشونو ژوندي پاتې کیږي (تر هغه چې معلومات دوام ولري). دا پدې مانا ده چې تر هغه چې تاسو روټینګ اعلان کړئ (تبادله) او قطار د انعطاف وړ وي، د قطار / روټینګ زیربنا به بیرته آنلاین راشي.

بې ثباته کتارونه او روټینګ لرې کیږي کله چې نوډ بیا پیل شي.

دوامداره پیغامونه

یوازې د دې لپاره چې کتار دوامدار وي پدې معنی ندي چې د دې ټول پیغامونه به د نوډ بیا پیل کولو ژوندي پاتې شي. یوازې هغه پیغامونه چې د خپرونکي لخوا ټاکل شوي دوامداره (دوامداره). دوامداره پیغامونه په بروکر باندې اضافي بار رامینځته کوي، مګر که د پیغام ضایع د منلو وړ نه وي، نو بله لاره نشته.

وريجې. 1. د پایښت اندازه

د قطار عکس العمل سره کلستر کول

د بروکر له لاسه د ژوندي پاتې کیدو لپاره ، موږ بې ځایه کیدو ته اړتیا لرو. موږ کولی شو ډیری RabbitMQ نوډونه په کلستر کې سره یوځای کړو، او بیا د ډیری نوډونو ترمنځ د قطارونو په نقل کولو سره اضافي بې ځایه کیدنه اضافه کړو. په دې توګه، که یو نوډ ناکام شي، موږ ډاټا له لاسه نه ورکوو او موجود پاتې کیږو.

د قطار عکس العمل:

• یو اصلي کتار (ماسټر)، کوم چې د لیکلو او لوستلو ټول حکمونه ترلاسه کوي
• یو یا څو عکسونه چې ټول پیغامونه او میټاډاټا د اصلي کتار څخه ترلاسه کوي. دا عکسونه د اندازه کولو لپاره ندي ، مګر په بشپړ ډول د بې ځایه کیدو لپاره.

وريجې. 2. د قطار عکس العمل

عکس العمل د مناسبې پالیسۍ لخوا تنظیم شوی. په دې کې تاسو کولی شئ د تکثیر کثافات او حتی نوډونه وټاکئ چې کتار باید موقعیت ولري. بېلګې:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (یو ماسټر او یو عکس)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

د خپرونکي تایید

د ثابت ریکارډ ترلاسه کولو لپاره، د خپرونکي تایید ته اړتیا ده. د دوی پرته، د پیغامونو له لاسه ورکولو خطر شتون لري. یو تایید خپرونکي ته لیږل کیږي وروسته له دې چې پیغام ډیسک ته ولیکل شي. RabbitMQ ډیسک ته پیغامونه د رسیدلو په وخت کې نه لیکي، مګر په دوره توګه، د څو سوه ملی ثانیو په سیمه کې. کله چې یوه کتار عکس العمل وي، یو اعتراف یوازې وروسته له هغه لیږل کیږي کله چې ټولو عکسونو خپل پیغام کاپي ډیسک ته لیکلي وي. دا پدې مانا ده چې د تاییداتو کارول ځنډ زیاتوي، مګر که د معلوماتو امنیت مهم وي، نو دا اړین دي.

د ناکامۍ کتار

کله چې یو بروکر پریږدي یا کریش شي، د قطار ټول مشران (ماسټران) په هغه نوډ کې ټکر کوي. کلستر بیا د هر ماسټر زوړ عکس غوره کوي او د نوي ماسټر په توګه یې هڅوي.

وريجې. 3. ډیری عکس العمل کتارونه او د دوی پالیسۍ

بروکر 3 ښکته ځي. په یاد ولرئ چې په بروکر 2 کې د قطار C عکس ماسټر ته وده ورکول کیږي. همدارنګه په یاد ولرئ چې په بروکر 1 کې د قطار C لپاره یو نوی عکس رامینځته شوی. RabbitMQ تل هڅه کوي چې ستاسو په پالیسیو کې مشخص شوي عکس العمل فاکتور وساتي.

وريجې. 4. بروکر 3 ناکام شو، د قطار C د ناکامۍ سبب کیږي

راتلونکی بروکر 1 راټیټ شو! موږ یوازې یو بروکر لرو. د قطار B عکس ماسټر ته وده ورکول کیږي.

عکس ایکس اینمکس

موږ د بروکر 1 بیرته راګرځولی دی. پرته له دې چې ډاټا د بروکر له لاسه ورکولو او بیرته ترلاسه کولو څخه څومره ښه پاتې کیږي، ټول عکس شوي قطار پیغامونه د بیا پیل کولو سره رد کیږي. دا مهمه ده چې یادونه وشي ځکه چې پایلې به ولري. موږ به په لنډه توګه دا اغیزې وګورو. نو بروکر 1 اوس بیا د کلستر غړی دی، او کلستر هڅه کوي د پالیسیو سره مطابقت ولري او له همدې امله په بروکر 1 کې عکسونه رامینځته کوي.

په دې حالت کې، د بروکر 1 له لاسه ورکول بشپړ وو، لکه څنګه چې ډاټا وه، نو د غیر عکس العمل قطار B په بشپړه توګه ورک شوی.

وريجې. 6. بروکر 1 خدمت ته راستنیږي

بروکر 3 بیرته آنلاین دی، نو د A او B کتارونه د دوی د HA پالیسیو د پوره کولو لپاره په هغې کې جوړ شوي عکسونه بیرته ترلاسه کوي. مګر اوس ټول اصلي کتارونه په یوه نوډ کې دي! دا مثالی نه دی، د نوډونو ترمنځ حتی ویش غوره دی. له بده مرغه، دلته د ماسټرانو د بیا انډول کولو لپاره ډیر اختیارونه شتون نلري. موږ به وروسته بیا دې مسلې ته راشو ځکه چې موږ اړتیا لرو لومړی د قطار ترکیب ته وګورو.

وريجې. 7. بروکر 3 خدمت ته راستنیږي. ټول اصلي کتارونه په یوه نوډ کې!

نو اوس تاسو باید یو نظر ولرئ چې څنګه عکسونه بې ځایه کیدو او د خطا زغم چمتو کوي. دا د واحد نوډ ناکامۍ په صورت کې شتون تضمینوي او د معلوماتو له لاسه ورکولو څخه ساتي. مګر موږ لا تر اوسه ندي ترسره کړي، ځکه چې په حقیقت کې دا خورا پیچلې ده.

همکاري

کله چې یو نوی عکس رامینځته کړئ، ټول نوي پیغامونه به تل دې عکس او نورو ته نقل شي. لکه څنګه چې په ماسټر کتار کې د موجوده معلوماتو لپاره، موږ کولی شو دا یو نوي عکس ته نقل کړو، کوم چې د ماسټر بشپړ کاپي کیږي. موږ کولی شو دا هم وټاکو چې موجوده پیغامونه تکرار نه کړو او پریږدو چې اصلي کتار او نوی عکس د وخت په تیریدو سره یوځای شي، نوي پیغامونه پای ته رسیږي او موجوده پیغامونه د اصلي کتار سر پریږدي.

دا همغږي کول په اتوماتيک ډول یا په لاسي ډول ترسره کیږي او د قطار پالیسۍ په کارولو سره اداره کیږي. راځئ چې یو مثال وګورو.

موږ دوه عکس لرونکي کتارونه لرو. قطار A په اوتومات ډول همغږي کیږي، او قطار B په لاسي ډول همغږي کیږي. دواړه کتارونه لس پیغامونه لري.

وريجې. 8. دوه کتارونه د مختلف ترکیب حالتونو سره

اوس موږ بروکر 3 له لاسه ورکوو.

وريجې. 9. بروکر 3 راټیټ شو

بروکر 3 بیرته خدمت ته راځي. کلستر په نوي نوډ کې د هر قطار لپاره عکس رامینځته کوي او په اتوماتيک ډول نوي قطار A د ماسټر سره همغږي کوي. په هرصورت، د نوي قطار B عکس خالي پاتې دی. پدې توګه موږ په قطار A کې بشپړ بې ځایه والی لرو او د موجوده قطار B پیغامونو لپاره یوازې یو عکس لرو.

وريجې. 10. د قطار A نوی عکس ټول موجود پیغامونه ترلاسه کوي، مګر د قطار B نوی عکس نه ترلاسه کوي.

لس نور پیغامونه په دواړو کتارونو کې راځي. بروکر 2 بیا کریش کیږي او قطار A بیرته زاړه عکس ته ځي، کوم چې په بروکر 1 کې دی. کله چې ناکام شي د معلوماتو ضایع شتون نلري. په B قطار کې، په ماسټر کې شل پیغامونه شتون لري او یوازې لس په عکس کې ځکه چې دې کتار هیڅکله اصلي لس پیغامونه نه دي نقل کړي.

وريجې. 11. کتار A د پیغامونو له لاسه ورکولو پرته بیرته بروکر 1 ته ځي

لس نور پیغامونه په دواړو کتارونو کې راځي. اوس بروکر 1 خرابیږي. قطار A په اسانۍ سره د پیغامونو له لاسه ورکولو پرته عکس ته ځي. په هرصورت، قطار B ستونزې لري. پدې مرحله کې موږ کولی شو یا هم شتون یا دوام غوره کړو.

که موږ غواړو د لاسرسي اصلاح کړو، نو پالیسي ha-promote-on-failure باید نصب شي تل. دا ډیفالټ ارزښت دی، نو تاسو نشئ کولی په ساده ډول پالیسي مشخص کړئ. پدې حالت کې ، موږ په لازمي ډول په غیر همغږي شوي عکسونو کې ناکامیو ته اجازه ورکوو. دا به د پیغامونو د ورکیدو لامل شي، مګر کتار به د لوستلو او لیکلو وړ پاتې شي.

وريجې. 12. قطار A د پیغامونو له لاسه ورکولو پرته بیرته بروکر 3 ته لیږدول کیږي. قطار B د لسو پیغامونو له لاسه ورکولو سره بیرته بروکر 3 ته ځي

موږ هم نصب کولی شو ha-promote-on-failure په معنی when-synced. په دې حالت کې، عکس ته د بیرته راګرځیدو پرځای، کتار به تر هغه پورې انتظار وکړي چې بروکر 1 د دې ډاټا سره آنلاین حالت ته راستانه شي. وروسته له دې چې بیرته راستانه شي، اصلي کتار بیرته په بروکر 1 کې پرته له کوم ډیټا ضایع کیږي. شتون د معلوماتو امنیت لپاره قرباني کیږي. مګر دا یو خطرناک حالت دی چې حتی د بشپړ ډیټا ضایع کیدو لامل کیدی شي ، کوم چې موږ به یې په لنډه توګه وګورو.

وريجې. 13. د بروکر 1 له لاسه ورکولو وروسته قطار B شتون نلري

تاسو شاید پوښتنه وکړئ، "ایا دا غوره ده چې هیڅکله د اتوماتیک همغږي نه کاروئ؟" ځواب دا دی چې همغږي کول د بندولو عملیات دي. د همغږي کولو پرمهال، اصلي کتار نشي کولی د لوستلو یا لیکلو عملیات ترسره کړي!

راځئ چې یو مثال وګورو. اوس موږ ډیر اوږد کتارونه لرو. دوی څنګه کولی شي دومره اندازې ته وده ورکړي؟ د څو دلیلونو لپاره:

• کتارونه په فعاله توګه نه کارول کیږي
• دا د لوړ سرعت قطارونه دي، او همدا اوس مصرف کونکي ورو دي
• دا د لوړ سرعت کتارونه دي، یو خنډ شتون لري او مصرف کونکي یې نیسي

وريجې. 14. دوه لوی کتارونه د مختلف ترکیب حالتونو سره

اوس بروکر 3 راځي.

وريجې. 15. بروکر 3 راټیټیږي، په هر کتار کې یو ماسټر او عکس پریږدي

بروکر 3 بیرته آنلاین راځي او نوي عکسونه رامینځته کیږي. اصلي کتار A نوي عکس ته د موجوده پیغامونو نقل کول پیل کوي، او پدې وخت کې قطار شتون نلري. د معلوماتو نقل کولو لپاره دوه ساعته وخت نیسي، په پایله کې د دې کتار لپاره دوه ساعته وخت نیسي!

په هرصورت، قطار B په ټوله دوره کې شتون لري. هغې د لاسرسي لپاره یو څه بې ځایه قرباني ورکړه.

وريجې. 16. د همغږي کولو پرمهال قطار شتون نلري

دوه ساعته وروسته، قطار A هم شتون لري او کولی شي د لوستلو او لیکلو منل پیل کړي.

اوسمهالونه

د همغږي کولو پرمهال د بندولو دا چلند د خورا لوی کتارونو سره د کلسترونو تازه کول ستونزمن کوي. په ځینو وختونو کې، ماسټر نوډ بیا پیل کولو ته اړتیا لري، پدې معنی چې یا د عکس بدلول یا د کتار غیر فعال کول پداسې حال کې چې سرور لوړیږي. که موږ لیږد غوره کړو، موږ به پیغامونه له لاسه ورکړو که چیرې عکسونه همغږي نه وي. د ډیفالټ په توګه، د بروکر بندیدو په جریان کې، یو غیر همغږي شوي عکس ته ناکامي نه ترسره کیږي. دا پدې مانا ده چې څومره ژر چې بروکر بیرته راشي، موږ هیڅ پیغام له لاسه نه ورکوو، یوازینی زیان یو ساده قطار و. د چلند قواعد کله چې یو بروکر منحل کیږي د پالیسۍ لخوا ټاکل کیږي ha-promote-on-shutdown. تاسو کولی شئ د دوو ارزښتونو څخه یو ترتیب کړئ:

• always= غیر همغږي شوي عکسونو ته لیږد فعال شوی
• when-synced= یوازې یو ترکیب شوي عکس ته لیږد ، که نه نو کتار د لوستلو وړ او د لیکلو وړ نه کیږي. لکه څنګه چې بروکر بیرته راستنیږي قطار بیرته خدمت ته راځي

یوه لاره یا بل ، د لوی کتارونو سره تاسو باید د معلوماتو له لاسه ورکولو او نه شتون تر مینځ غوره کړئ.

کله چې شتون د ډیټا امنیت ښه کوي

د پریکړې کولو دمخه په پام کې نیولو سره یو بل پیچلتیا شتون لري. پداسې حال کې چې اتوماتیک ترکیب د بې ځایه کیدو لپاره غوره دی، دا څنګه د معلوماتو امنیت اغیزه کوي؟ البته، د ښه بې ځایه کیدو سره، RabbitMQ لږ احتمال لري چې موجوده پیغامونه له لاسه ورکړي، مګر د خپرونکو څخه د نوي پیغامونو په اړه څه؟

دلته تاسو باید لاندې ټکي په پام کې ونیسئ:

• ایا خپرونکی کولی شي په ساده ډول یوه تېروتنه راوباسي او د اپ سټریم خدمت یا کارونکي وروسته بیا هڅه وکړي؟
• ایا خپرونکی کولی شي پیغام په ځایی یا ډیټابیس کې خوندي کړي ترڅو وروسته بیا هڅه وکړي؟

که چیرې خپرونکی یوازې پیغام رد کړي، نو په حقیقت کې، د لاسرسي ښه کول د معلوماتو امنیت هم ښه کوي.

په دې توګه، یو توازن باید په لټه کې شي، او حل په ځانګړي حالت پورې اړه لري.

د ha-promote-on-failure = کله چې همغږي کیږي ستونزې

ایډا ha-promote-on-failure= کله چې همغږي شي دا دی چې موږ غیر همغږي شوي عکس ته د بدلیدو مخه نیسو او پدې توګه د معلوماتو له لاسه ورکولو څخه مخنیوی کوو. کتار د لوستلو وړ یا د لیکلو وړ پاتې کیږي. پرځای یې، موږ هڅه کوو چې ویجاړ شوی بروکر د دې ډاټا سره بیرته ترلاسه کړو ترڅو دا د معلوماتو له لاسه ورکولو پرته د ماسټر په توګه فعالیت بیا پیل کړي.

مګر (او دا لوی دی مګر) که بروکر خپل معلومات له لاسه ورکړي، نو موږ یوه لویه ستونزه لرو: قطار ورک شوی! ټول معلومات ورک دي! حتی که تاسو عکسونه لرئ چې ډیری یې د اصلي کتار سره یوځای کیږي، دا عکسونه هم پریښودل کیږي.

د ورته نوم سره د نوډ بیا اضافه کولو لپاره، موږ کلستر ته وایو چې ورک شوی نوډ هیر کړي (د کمانډ سره rabbitmqctl forget_cluster_node) او د ورته کوربه نوم سره نوی بروکر پیل کړئ. پداسې حال کې چې کلستر ورک شوی نوډ په یاد لري، دا زاړه قطار او غیر همغږي شوي عکسونه یادوي. کله چې یو کلستر ته ویل کیږي چې د یتیم نوډ هیر کړي، هغه کتار هم هیر شوی. اوس موږ اړتیا لرو چې دا بیا اعلان کړو. موږ ټول معلومات له لاسه ورکړل، که څه هم موږ د ډیټا د جزوی سیټ سره عکسونه درلودل. دا به غوره وي چې غیر همغږي شوي عکس ته لاړشئ!

له همدې امله، د لاسي ترکیب (او د همغږي کولو ناکامي) سره په ترکیب کې ha-promote-on-failure=when-syncedزما په نظر، ډیر خطرناک. اسناد وايي چې دا اختیار د معلوماتو امنیت لپاره شتون لري، مګر دا یو دوه اړخیز چاقو دی.

ماسټر بیا توازن کول

لکه څنګه چې ژمنه شوې، موږ په یو یا څو نوډونو کې د ټولو ماسټرانو د راټولولو ستونزې ته راستون شو. دا حتی د رولینګ کلستر تازه کولو په پایله کې پیښ کیدی شي. په درې نوډ کلستر کې، ټول ماسټر کتارونه به په یو یا دوه نوډونو کې راټول شي.

د ماسټرانو بیا توازن کول د دوه دلیلونو لپاره ستونزمن کیدی شي:

• د بیا انډول کولو لپاره هیڅ ښه وسیله شتون نلري
• د قطار همغږي کول

د بیا انډول کولو لپاره دریم اړخ شتون لري نښلول، کوم چې په رسمي ډول نه دی تائید شوی. د RabbitMQ لارښود کې د دریمې ډلې پلگ انونو په اړه وویل: "پلگ ان ځینې اضافي تشکیلات او د راپور ورکولو وسیلې چمتو کوي ، مګر د RabbitMQ ټیم لخوا ملاتړ یا تایید شوی نه دی. په خپل خطر کې وکاروئ."

د HA پالیسیو له لارې د اصلي کتار حرکت کولو لپاره یو بل چل شتون لري. په لارښود کې یادونه شوې سکریپټ د دى لپاره. دا په دې ډول کار کوي:

• د لنډمهاله پالیسۍ په کارولو سره ټول عکسونه لرې کوي چې د موجوده HA پالیسي په پرتله لوړ لومړیتوب لري.
• د نوډ حالت کارولو لپاره د HA لنډمهاله پالیسي بدلوي، د نوډ مشخص کول چې ماسټر کتار باید لیږدول شي.
• د فشار مهاجرت لپاره قطار همغږي کوي.
• د مهاجرت بشپړیدو وروسته، لنډمهاله پالیسي ړنګوي. د HA لومړنۍ پالیسي اغیزمن کیږي او د عکسونو اړین شمیر رامینځته کیږي.

منفي اړخ دا دی چې دا طریقه ممکن کار ونکړي که تاسو لوی کتارونه یا سخت بې ځایه اړتیاوې ولرئ.

اوس راځئ وګورو چې څنګه د RabbitMQ کلسترونه د شبکې برخې سره کار کوي.

د ارتباط له لاسه ورکول

د ویشل شوي سیسټم نوډونه د شبکې لینکونو سره وصل دي، او د شبکې لینکونه کیدای شي منحل شي. د بندیدو فریکوینسي په محلي زیربنا یا د ټاکل شوي بادل اعتبار پورې اړه لري. په هر حالت کې، ویشل شوي سیسټمونه باید د دوی سره مقابله وکړي. یوځل بیا موږ د شتون او دوام تر مینځ انتخاب لرو ، او بیا ښه خبر دا دی چې RabbitMQ دواړه اختیارونه چمتو کوي (یوازې په ورته وخت کې نه).

د RabbitMQ سره موږ دوه اصلي اختیارونه لرو:

• منطقي ویش ته اجازه ورکړئ (سپلایټ دماغ). دا شتون تضمینوي، مګر ممکن د معلوماتو ضایع کیدو لامل شي.
• منطقي جلا کول غیر فعال کړئ. کیدای شي د لنډ مهاله شتون له لاسه ورکولو پایله ولري پدې پورې اړه لري چې پیرودونکي څنګه کلستر سره وصل کیږي. په دوه نوډ کلستر کې د بشپړ نشتوالي لامل هم کیدی شي.

مګر منطقي جلا کول څه دي؟ دا هغه وخت دی چې یو کلستر د شبکې د اتصال له لاسه ورکولو له امله په دوه برخو ویشل کیږي. په هر اړخ کې، عکسونه یو ماسټر ته وده ورکول کیږي، نو په پای کې په هر قطار کې څو ماسټران شتون لري.

وريجې. 17. اصلي کتار او دوه عکسونه، هر یو په جلا نوډ کې. بیا د شبکې ناکامي پیښیږي او یو عکس جلا کیږي. جلا شوی نوډ ګوري چې نور دوه راوتلي دي او خپل عکسونه ماسټر ته هڅوي. موږ اوس دوه اصلي کتارونه لرو، دواړه د لیکلو او لوستلو وړ.

که خپرونکي دواړه ماسټرانو ته معلومات واستوي، موږ د کتار دوه متنوع کاپي سره پای ته ورسوو.

د RabbitMQ مختلف حالتونه یا هم شتون یا دوام چمتو کوي.

له پامه غورځول (ډیفالټ)

دا حالت د لاسرسي ډاډ ورکوي. د ارتباط له لاسه ورکولو وروسته، منطقي جلا کول واقع کیږي. وروسته له دې چې ارتباط بحال شي، مدیر باید پریکړه وکړي چې کومې برخې ته لومړیتوب ورکړي. له لاسه ورکونکی اړخ به بیا پیل شي او په دې اړخ کې ټول راټول شوي معلومات به ورک شي.

وريجې. 18. درې خپرونکي د دریو بروکرانو سره تړاو لري. په داخلي توګه، کلستر ټولې غوښتنې په بروکر 2 کې اصلي کتار ته رسوي.

اوس موږ بروکر 3 له لاسه ورکوو. هغه ګوري چې نور بروکران راوتلي او ماسټر ته یې خپل عکس هڅوي. دا څنګه منطقي جلا کول واقع کیږي.

وريجې. 19. منطقي څانګه (د دماغ ویش). ریکارډونه دوه اصلي کتارونو ته ځي، او دوه نقلونه توپیر لري.

ارتباط بیا رغول شوی، مګر منطقي جلا کول پاتې دي. مدیر باید په لاسي ډول له لاسه ورکولو اړخ غوره کړي. په لاندې حالت کې، مدیر د بروکر 3 ریبوټ کوي. ټول هغه پیغامونه چې هغه یې د لیږدولو اداره نه کوله ورک شوي.

وريجې. 20. مدیر د بروکر 3 غیر فعالوي.

وريجې. 21. مدیر د بروکر 3 پیل کوي او دا کلستر سره یوځای کیږي، ټول هغه پیغامونه چې هلته پاتې شوي له لاسه ورکوي.

د ارتباط له لاسه ورکولو پرمهال او د هغې له رغولو وروسته، کلستر او دا کتار د لوستلو او لیکلو لپاره شتون درلود.

د اتوماتیک حالت

د Ignore حالت ته ورته کار کوي، پرته له دې چې کلستر پخپله د نښلولو او بیا رغولو وروسته له لاسه ورکولو اړخ غوره کوي. له لاسه ورکونکی اړخ خالي کلستر ته راستنیږي، او کتار ټول هغه پیغامونه له لاسه ورکوي چې یوازې هغه لوري ته لیږل شوي.

د اقلیت حالت مخه ونیسئ

که موږ نه غواړو منطقي ویشلو ته اجازه ورکړو، نو زموږ یوازینۍ اختیار دا دی چې د کلستر ویش وروسته په کوچني اړخ کې لوستل او لیکل رد کړو. کله چې بروکر ګوري چې دا په کوچني اړخ کې دی، دا کار وځنډوي، دا دا دی، دا ټول موجوده اړیکې بندوي او کوم نوي ردوي. یو ځل په ثانیه کې دا د ارتباط بیا رغونه ګوري. یوځل چې ارتباط بحال شي ، دا عملیات بیا پیل کوي او کلسټر سره یوځای کیږي.

وريجې. 22. درې خپرونکي د دریو بروکرانو سره تړاو لري. په داخلي توګه، کلستر ټولې غوښتنې په بروکر 2 کې اصلي کتار ته رسوي.

بروکر 1 او 2 بیا د بروکر 3 څخه جلا کیږي. د دې پرځای چې خپل عکس ماسټر ته وده ورکړي، بروکر 3 وځنډوي او شتون نلري.

وريجې. 23. بروکر 3 ځنډوي، ټول مشتریان منقطع کوي، او د پیوستون غوښتنې ردوي.

یوځل چې ارتباط بحال شي ، دا کلستر ته راستون کیږي.

راځئ چې یو بل مثال وګورو چیرې چې اصلي قطار په بروکر 3 کې دی.

وريجې. 24. په بروکر 3 کې اصلي کتار.

بیا د ارتباط ورته زیان پیښیږي. بروکر 3 وقفه کوي ځکه چې دا په کوچني اړخ کې دی. له بلې خوا، نوډونه ګوري چې بروکر 3 راټیټ شوی، نو د بروکرز 1 او 2 څخه زوړ عکس ماسټر ته وده ورکول کیږي.

وريجې. 25. بروکر 2 ته لیږد که چیرې بروکر 3 شتون ونلري.

کله چې ارتباط بحال شي، بروکر 3 به کلستر سره یوځای شي.

وريجې. 26. کلستر بیرته عادي فعالیت ته راستانه شوی.

دلته د پوهیدو لپاره مهم شی دا دی چې موږ ثبات ترلاسه کوو، مګر موږ کولی شو شتون هم ترلاسه کړو، که موږ به په بریالیتوب سره ډیری برخې ته مراجعین انتقال کړو. د ډیری حاالتو لپاره، زه به په شخصي توګه د پام وړ اقلیت حالت غوره کړم، مګر دا واقعیا په انفرادي قضیه پورې اړه لري.

د شتون ډاډ ترلاسه کولو لپاره، دا مهمه ده چې ډاډ ترلاسه کړئ چې پیرودونکي په بریالیتوب سره کوربه سره نښلوي. راځئ چې زموږ اختیارونه وګورو.

د پیرودونکو ارتباط یقیني کول

موږ ډیری اختیارونه لرو چې څنګه د ارتباط له لاسه ورکولو وروسته د کلستر اصلي برخې یا کاري نوډونو ته (د یو نوډ ناکامیدو وروسته) مراجعینو ته لارښود کړو. لومړی، راځئ چې په یاد ولرو چې یو ځانګړی قطار په یو ځانګړي نوډ کې کوربه شوی، مګر روټینګ او پالیسۍ په ټولو نوډونو کې تکرار شوي. پیرودونکي کولی شي له هر نوډ سره وصل شي، او داخلي لارې به دوی ته لارښوونه وکړي چیرې چې دوی ورته اړتیا لري. مګر کله چې یو نوډ وځنډول شي، دا اړیکې ردوي، نو پیرودونکي باید د بل نوډ سره وصل شي. که چیرې نوډ راټیټ شي، نو لږ څه شتون لري چې هغه کولی شي.

زموږ اختیارونه:

• کلستر ته د بار بیلنسر په کارولو سره لاسرسی کیږي چې په ساده ډول د نوډونو له لارې تیریږي او پیرودونکي بیا د وصل کیدو هڅه کوي ترڅو بریالي شي. که یو نوډ ښکته یا معطل شوی وي، نو د دې نوډ سره د نښلولو هڅې به ناکامې وي، مګر وروسته هڅې به نورو سرورونو ته لاړ شي (په راؤنډ رابین فیشن کې). دا د اتصال د لنډ مهاله ضایع کیدو یا د خراب شوي سرور لپاره مناسب دی چې ژر تر ژره بیرته راوړل شي.
• د بار بیلنسر له لارې کلستر ته لاسرسی ومومئ او د لیست څخه ځنډول شوي / ناکام شوي نوډونه ژر تر ژره کشف کړئ. که موږ دا په چټکۍ سره ترسره کړو، او که مراجعین د پیوستون بیا هڅه وکړي، نو موږ به دوامداره شتون ترلاسه کړو.
• هر پیرودونکي ته د ټولو نوډونو لیست ورکړئ، او پیرودونکي په تصادفي ډول یو له دوی څخه غوره کوي کله چې وصل شي. که چیرې دا د نښلولو هڅه کولو کې تېروتنه ترلاسه کړي، دا په لیست کې راتلونکي نوډ ته ځي تر هغه چې دا وصل نشي.
• د DNS په کارولو سره د ناکام / تعلیق شوي نوډ څخه ترافیک لرې کړئ. دا د کوچني TTL په کارولو سره ترسره کیږي.

موندنو

د RabbitMQ کلستر کول خپلې ګټې او زیانونه لري. ترټولو جدي زیانونه دا دي:

• کله چې په کلستر کې شامل شي، نوډونه خپل معلومات ردوي؛
• د همغږي بندول د دې لامل کیږي چې قطار شتون ونلري.

ټولې سختې پریکړې د دې دوه معماري ځانګړتیاو څخه رامینځته کیږي. که RabbitMQ کولی شي ډاټا خوندي کړي کله چې کلستر بیا یوځای شي، نو بیا همغږي کول به ګړندي وي. که دا د غیر بلاک کولو همغږي کولو وړ و ، نو دا به د لوی قطارونو ملاتړ وکړي. د دې دوه مسلو حل کول به د RabbitMQ فعالیت د غلطۍ زغمونکي او خورا موجود پیغام رسولو ټیکنالوژۍ په توګه ښه کړي. زه به په لاندې حاالتو کې د کلستر کولو سره د RabbitMQ وړاندیز کولو کې زړه نازړه شم:

• بې اعتباره شبکه.
• د باور وړ ذخیره کول.
• ډېر اوږده کتارونه.

کله چې دا د لوړ شتون ترتیباتو ته راځي، لاندې په پام کې ونیسئ:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (يا autoheal)
• دوامداره پیغامونه
• ډاډ ترلاسه کړئ چې پیرودونکي د فعال نوډ سره وصل کیږي کله چې ځینې نوډ ناکام شي

د ثبات لپاره (د معلوماتو امنیت)، لاندې ترتیبات په پام کې ونیسئ:

• خپرونکی د مصرف کونکي اړخ تصدیق کوي او لارښود اعترافونه
• ha-promote-on-failure=when-synced، که خپرونکي کولی شي وروسته بیا هڅه وکړي او که تاسو خورا معتبر ذخیره لرئ! بل یې واچوئ =always.
• ha-sync-mode=automatic (مګر د لوی غیر فعال کتارونو لپاره لارښود حالت ته اړتیا لیدل کیدی شي؛ دا هم په پام کې ونیسئ چې ایا نه شتون به د پیغامونو له لاسه ورکولو لامل شي)
• د اقلیت حالت مخه ونیسئ
• دوامداره پیغامونه

موږ تر اوسه د خطا زغم او لوړ شتون ټولې مسلې نه دي پوښلي؛ د مثال په توګه، څنګه په خوندي توګه اداري پروسیجرونه ترسره کړئ (لکه د رولینګ تازه معلومات). موږ د فدراسیون او شاول پلگ ان په اړه هم خبرې کولو ته اړتیا لرو.

که ما نور څه له لاسه ورکړي وي، مهرباني وکړئ ما ته خبر راکړئ.

زما هم وګورئ پوسته، چیرې چې زه د ډاکر او بلاکډ په کارولو سره د 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