В وروستنی مقاله موږ د غلطۍ زغم او لوړ شتون لپاره 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=ریښتیا د کنټرولر نوډ ته اجازه ورکوي چې په اتوماتيک ډول مشران بیرته غوره شوي نقلونو ته وټاکي او په دې توګه یونیفورم توزیع بحال کړي.
• مدیر کولی شي سکریپټ پرمخ بوځي kafka-preferred-replica-election.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=ټول، تصدیق وروسته له هغه لیږل کیږي چې په ISR کې ټول نقلونه محلي لاګ ته پیغام ولیکي

د کافکا په اصطلاح کې، که چیرې ISR یو پیغام خوندي کړي، دا "ژمنه" ده. Acks = ټول ترټولو خوندي انتخاب دی، مګر اضافي ځنډ هم زیاتوي. راځئ چې د ناکامۍ دوه مثالونه وګورو او څنګه د مختلف 'acks' اختیارونه د ISR مفهوم سره تعامل کوي.

Acks=1 او ISR

پدې مثال کې ، موږ به وګورو چې که مشر د ټولو پیروانو هر پیغام خوندي کیدو ته انتظار ونه کړي ، نو د معلوماتو ضایع ممکن وي که چیرې رهبر ناکام شي. غیر همغږي شوي پیروان ته تګ کول د تنظیم کولو له لارې فعال یا غیر فعال کیدی شي unclean.leader.election.enable.

په دې مثال کې، جوړونکی د 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=ریښتیا. که چیرې دا نصب شي غلط، بیا به لیږد نه پیښیږي او د لوستلو او لیکلو ټولې غوښتنې به رد شي. په دې حالت کې، موږ د بروکر 1 لپاره انتظار کوو چې په نقل کې د هغه د پاتې معلوماتو سره بیرته راشي، کوم چې بیا به مشرتابه په غاړه واخلي.

وريجې. 11. بروکر 1 گرځي. کله چې ناکامي واقع کیږي، یو لوی شمیر پیغامونه له لاسه ورکوي

تولید کونکی د وروستي بروکر سره اړیکه رامینځته کوي او ګوري چې هغه اوس د برخې مشر دی. هغه بروکر 3 ته د پیغامونو لیږل پیل کوي.

وريجې. 12. د لنډې وقفې وروسته، پیغامونه بیا 0 برخې ته لیږل کیږي

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

Acks = ټول او ISR

راځئ چې دا سناریو بیا تکرار کړو، مګر سره acks = ټول. بروکر 3 د څلورو ثانیو اوسط ځنډ لري. جوړونکی د دې سره یو پیغام لیږي acks = ټول، او اوس چټک ځواب نه ترلاسه کوي. مشر د پیغام لپاره انتظار کوي چې په ISR کې د ټولو نقلونو لخوا خوندي شي.

وريجې. 13. ISR د دریو نقلونو سره. یو یې سست دی، چې په پایله کې د ثبت کولو ځنډ رامنځته کیږي

د څلورو ثانیو اضافي ځنډ وروسته، بروکر 2 یو اک لیږي. ټول نقلونه اوس په بشپړ ډول نوي شوي.

وريجې. 14. ټول نقلونه پیغامونه خوندي کوي او ack لیږل کیږي

بروکر 3 اوس نور شاته راځي او د ISR څخه لیرې شوی. ځنډ د پام وړ کم شوی ځکه چې په ISR کې ورو ورو نقلونه شتون نلري. بروکر 2 اوس یوازې د بروکر 1 لپاره انتظار کوي، او هغه د 500 ms منځنۍ وقفه لري.

وريجې. 15. د بروکر 3 نقل د ISR څخه لیرې شوی

بیا بروکر 2 راټیټیږي او مشرتابه د پیغامونو له لاسه ورکولو پرته بروکر 1 ته ځي.

وريجې. 16. بروکر 2 گرځي

جوړونکی یو نوی مشر پیدا کوي او هغه ته د پیغامونو لیږل پیل کوي. ځنډ نور هم کم شوی ځکه چې ISR اوس یو نقل لري! له همدې امله اختیار acks = ټول بې ځایه نه اضافه کوي.

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

بیا بروکر 1 کریش کیږي او لیډ د 3 پیغامونو له لاسه ورکولو سره بروکر 14238 ته ځي!

وريجې. 18. بروکر 1 مړ کیږي او د ناپاک ترتیب سره د مشرتابه لیږد د پراخه معلوماتو ضایع کیدو پایله لري

موږ نشو کولی اختیار نصب کړو unclean.leader.election.enable په معنی رښتيا. په ډیفالټ کې دا مساوي دی غلط. ترتیبات acks = ټول с unclean.leader.election.enable=ریښتیا د ځینې اضافه معلوماتو امنیت سره لاسرسی چمتو کوي. مګر لکه څنګه چې تاسو لیدلی شئ، موږ لاهم کولی شو پیغامونه له لاسه ورکړو.

مګر څه که موږ غواړو د معلوماتو امنیت ډیر کړو؟ تاسو کولی شئ واچوئ 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. د ISRs شمیر د 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 دا مهمه ده چې پیرودونکي د ناکامۍ وروسته سم نوډونو ته لاسرسی ومومي او ومومي.

د کافکا توافق معمار

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

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

زوکیپر د کلستر حالت ذخیره کوي:

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

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

د مثال په توګه، راځئ چې د لسو برخو او د 3 د نقل کولو فکتور سره یوه نوې موضوع واخلو. کنټرولر باید د هرې برخې لپاره یو مشر وټاکي، هڅه کوي چې مشران په غوره توګه د بروکرانو ترمنځ وویشي.

د هرې برخې کنټرولر لپاره:

• په Zookeeper کې د ISR او مشر په اړه تازه معلومات؛
• هر بروکر ته د مشر او ISRC کمانډ لیږي چې د دې برخې نقل کوربه کوي، د ISR او مشر په اړه بروکرانو ته خبر ورکوي.

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

هر مشر د ISRs استخدام مسولیت لري. ترتیبات replica.lag.time.max.ms ټاکي چې څوک به هلته ننوځي. کله چې ISR بدل شي، مشر زوکیپر ته نوي معلومات لیږدوي.

زوکیپر تل د هر ډول بدلونونو څخه خبر وي ترڅو د ناکامۍ په صورت کې مدیریت نوي مشر ته په اسانۍ سره لیږدوي.

وريجې. 21. د کافکا توافق

د تکرار پروتوکول

د نقل کولو توضیحاتو پوهیدل تاسو سره د احتمالي معلوماتو ضایع کیدو سناریو په ښه پوهیدو کې مرسته کوي.

د نمونې اخیستلو پوښتنې، د ننوتلو پای آفسیټ (LEO) او د لوړ اوبو نښه (HW)

موږ په پام کې نیولي چې پیروان په وخت سره مشر ته د راوړلو غوښتنې لیږي. ډیفالټ وقفه 500ms ده. دا د 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 معلوم کړي، او بیا دې آفسټ ته لاګ لنډ کړي. دا به بیا په دې آفسیټ کې د دوراني راوړلو غوښتنې پیل کړي.

یو پیروونکی ممکن د لاندې دلایلو لپاره لاګ پرې کولو ته اړتیا ولري:

• کله چې یو مشر ناکام شي، د ISR په ترتیب کې لومړی پیروونکی چې د زوکیپر سره راجستر شوی ټاکنې وګټي او مشر شي. په ISR کې ټول پیروان، که څه هم "همغږي" ګڼل کیږي، ممکن د پخواني مشر څخه د ټولو پیغامونو کاپي نه وي ترلاسه کړي. دا په بشپړه توګه ممکنه ده چې ځانګړی پیروونکی تر ټولو تازه کاپي ونه لري. کافکا ډاډ ورکوي چې د نقلونو تر مینځ هیڅ توپیر شتون نلري. په دې توګه، د توپیرونو څخه د مخنیوي لپاره، هر پیروونکی باید د هغه د ټاکنو په وخت کې د نوي مشر د HW ارزښت ته خپل لاګ کم کړي. دا یو بل دلیل دی چې ولې تنظیم کول acks = ټول د دوام لپاره خورا مهم.
• پیغامونه په منظم ډول ډیسک ته لیکل کیږي. که ټول کلستر نوډونه په ورته وخت کې ناکام شي، نو بیا د مختلف آفسیټونو سره نقلونه به په ډیسکونو کې زیرمه شي. دا ممکنه ده چې کله بروکرز بیرته آنلاین راشي، نوی مشر چې ټاکل کیږي د خپلو پیروانو تر شا وي ځکه چې هغه د نورو څخه مخکې ډیسک ته خوندي شوی و.

د کلستر سره یوځای کیدل

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

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

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

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

کافکا د RabbitMQ په پرتله ډیرې برخې لري، نو دا د چلند خورا پیچلي سیټ لري کله چې کلستر منحل شي. مګر کافکا په اصل کې د کلسترونو لپاره ډیزاین شوی و، نو حلونه خورا ښه فکر شوي.

لاندې د ارتباط د ناکامۍ څو سناریوګانې دي:

• 1 سناریو: پیروونکی مشر نه ویني، مګر بیا هم ژوبڼ ته ګوري.
• سناریو 2: مشر هیڅ پیروان نه ګوري، مګر بیا هم ژوبڼ ته ګوري.
• دریمه صحنه: پیروونکی مشر ویني، خو ژوبڼ ته نه ګوري.
• 4 سناریو: مشر پیروان ګوري، مګر ژوبڼ نه ګوري.
• 5 سناریو: پیروونکی د کافکا له نورو نوډونو او زوکیپر څخه په بشپړ ډول جلا دی.
• 6 سناریو: مشر د کافکا له نورو نوډونو او زوکیپر څخه په بشپړه توګه جلا دی.
• 7 سناریو: د کافکا کنټرولر نوډ نشي کولی بل کافکا نوډ وګوري.
• 8 سناریو: د کافکا کنټرولر زوکیپر نه ګوري.

هره سناریو خپل چلند لري.

1 سناریو: پیروونکی مشر نه ګوري، مګر بیا هم زوکیپر ګوري

وريجې. 22. 1 سناریو: د دریو نقلونو ISR

د ارتباط ناکامي بروکر 3 د بروکرز 1 او 2 څخه جلا کوي، مګر د زوکیپر څخه نه. بروکر 3 نور نشي کولی د راوړلو غوښتنې واستوي. د وخت په تیریدو وروسته replica.lag.time.max.ms دا د ISR څخه لیرې شوی او د پیغام په ژمنو کې برخه نه اخلي. یوځل چې ارتباط بحال شي ، دا به د غوښتنې ترلاسه کولو بیا پیل کړي او د ISR سره یوځای شي کله چې دا د مشر سره اړیکه ونیسي. زوکیپر به پینګ ترلاسه کولو ته دوام ورکړي او ګومان وکړي چې بروکر ژوندی او ښه دی.

وريجې. 23. 1 سناریو: بروکر د ISR څخه لیرې کیږي که چیرې د replica.lag.time.max.ms وقفې کې د هغې څخه د راوړلو غوښتنه ترلاسه نشي.

هیڅ سپلیټ دماغ یا نوډ تعلیق شتون نلري لکه په RabbitMQ کې. پرځای یې، بې ځایه کیدنه کمه شوې.

2 سناریو: مشر هیڅ پیروان نه ګوري، مګر بیا هم ژوبڼ ته ګوري

وريجې. 24. سناریو 2. مشر او دوه پیروان

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

وريجې. 25. سناریو 2. ISR یوازې مشر ته راټیټ شوی

صحنه 3. پیروونکی مشر ویني، خو ژوبڼ ته نه ګوري

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

وريجې. 26. دریمه صحنه: پیروونکی رهبر ته د غوښتنې د ترلاسه کولو لپاره دوام ورکوي

4. سناریو مشر پیروان ویني، خو ژوبڼ نه ګوري

وريجې. 27. سناریو 4. مشر او دوه پیروان

مشر له زوکیپر څخه جلا کیږي، مګر د پیروانو سره د دلالانو څخه نه.

وريجې. 28. 4 سناریو: مشر له ژوبڼ څخه جلا شوی

یو څه وخت وروسته ، زوکیپر به د بروکر ناکامي ثبت کړي او کنټرولر ته به یې خبر کړي. هغه به د خپلو پلویانو په منځ کې نوی مشر وټاکي. په هرصورت، اصلي مشر به فکر کولو ته دوام ورکړي چې دا مشر دی او د ننوتلو منلو ته به دوام ورکړي acks=1. پیروان نور هغه ته د ترلاسه کولو غوښتنې نه لیږي ، نو هغه به دوی مړه وګڼي او هڅه به وکړي چې ISR ځان ته راکم کړي. مګر څرنګه چې دا د زوکیپر سره اړیکه نلري، نو دا به ونه شي کولی دا کار وکړي، او په دې وخت کې به د نورو ننوتلو منلو څخه انکار وکړي.

پېغامونه acks = ټول یو اعتراف به ترلاسه نکړي ځکه چې ISR لومړی ټول نقلونه بدلوي، او پیغامونه دوی ته نه رسیږي. کله چې اصلي مشر هڅه کوي دوی له ISR څخه لرې کړي، نو دا به د دې کولو توان ونلري او د هر ډول پیغامونو منلو مخه ونیسي.

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

وريجې. 29. سناریو 4. په بروکر 1 کې مشر د شبکې له بیا رغولو وروسته پیروونکی کیږي

5 سناریو: پیروونکی د کافکا له نورو نوډونو او زوکیپر څخه په بشپړ ډول جلا دی

پیروونکی په بشپړ ډول د کافکا له نورو نوډونو او زوکیپر څخه جلا دی. هغه په ​​ساده ډول خپل ځان له ISR څخه لرې کوي تر هغه چې شبکه بیرته جوړه شي، او بیا د نورو سره یوځای کیږي.

وريجې. 30. 5 سناریو: جلا شوی پیروونکی د ISR څخه لیرې شوی

6 سناریو: مشر د کافکا له نورو نوډونو او زوکیپر څخه په بشپړه توګه جلا دی

وريجې. 31. سناریو 6. مشر او دوه پیروان

مشر په بشپړه توګه د خپلو پیروانو، کنټرولر او زوکیپر څخه جلا دی. د لنډې مودې لپاره دا به د ننوتلو منلو ته دوام ورکړي acks=1.

وريجې. 32. شپږمه صحنه: مشر له نورو کافکا او زوکیپر نوډونو څخه جلا کول

د ختمیدو وروسته غوښتنې نه ترلاسه کول replica.lag.time.max.ms، دا به هڅه وکړي چې ISR ځان ته لنډ کړي ، مګر دا به ونه شي کولی ځکه چې د زوکیپر سره اړیکه نلري ، نو دا به د لیکلو منلو مخه ونیسي.

په ورته وخت کې ، زوکیپر به جلا شوی بروکر د مړ په توګه په نښه کړي او کنټرولر به نوی مشر وټاکي.

وريجې. 33. سناریو 6. دوه مشران

اصلي مشر ممکن د څو ثانیو لپاره ننوتل ومني، مګر بیا د هر پیغام منلو مخه نیسي. پیرودونکي په هر 60 ثانیو کې د وروستي میټاډاټا سره تازه کیږي. دوی به د مشر له بدلون څخه خبر شي او نوي مشر ته به د ننوتلو لیږل پیل کړي.

وريجې. 34. شپږمه سناریو: جوړونکي نوي مشر ته ځي

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

وريجې. 35. 6 سناریو: اصلي مشر د شبکې ارتباط بیا رغولو وروسته پیروونکی کیږي

په دې حالت کې، منطقي جلا کول ممکن د لنډې مودې لپاره واقع شي، مګر یوازې که acks=1 и min.insync.replicas همدارنګه 1. منطقي جلا کول په اوتومات ډول د شبکې له رغولو وروسته پای ته رسیږي، کله چې اصلي مشر پوه شي چې هغه نور مشر نه دی، یا کله چې ټول پیرودونکي پوه شي چې مشر بدل شوی او نوي مشر ته لیکل پیل کوي - هر هغه څه چې لومړی پیښیږي. په هر حالت کې، ځینې پیغامونه به ورک شي، مګر یوازې سره acks=1.

د دې سناریو یو بل ډول شتون لري چیرې چې د شبکې له ویشلو دمخه ، پیروان شاته شول او مشر یوازې ځان ته ISR فشار ورکړ. دا بیا د ارتباط له لاسه ورکولو له امله جلا کیږي. یو نوی مشر ټاکل کیږي، مګر اصلي مشر د ننوتلو منلو ته دوام ورکوي، حتی acks = ټولځکه چې په ISR کې له هغه پرته بل څوک نشته. دا ریکارډونه به له لاسه ورکړل شي کله چې شبکه بحال شي. د دې اختیار څخه د مخنیوي یوازینۍ لار ده min.insync.replicas = 2.

7 سناریو: د کافکا کنټرولر نوډ نشي کولی بل کافکا نوډ وګوري

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

8 سناریو: د کافکا کنټرولر زوکیپر نه ګوري

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

د سناریوګانو څخه پایلې

موږ ګورو چې د پیروکار ارتباط له لاسه ورکول د پیغام له لاسه ورکولو پایله نه لري ، مګر په ساده ډول په لنډمهاله توګه بې ځایه کیدل کموي تر هغه چې شبکه بحال نشي. دا، البته، د معلوماتو له لاسه ورکولو لامل کیدی شي که چیرې یو یا ډیر نوډونه ورک شي.

که مشر د اتصال له لاسه ورکولو له امله له زوکیپر څخه جلا شي ، نو دا کیدی شي د پیغامونو له لاسه ورکولو لامل شي. acks=1. د زوکیپر سره د اړیکو نشتوالی د دواړو مشرانو سره د لنډ منطقي ویش لامل کیږي. دا ستونزه د پیرامیټر لخوا حل کیږي acks = ټول.

پارسيم min.insync.replicas په دوه یا ډیرو نقلونو کې اضافي تضمین چمتو کوي چې دا ډول لنډمهاله سناریوګانې به د 6 سناریو په څیر د ورک شوي پیغامونو پایله ونلري.

د ورک شوي پیغامونو لنډیز

راځئ چې ټولې هغه لارې لیست کړو چې تاسو کولی شئ په کافکا کې ډاټا له لاسه ورکړئ:

• د هر مشر ناکامي که چیرې پیغامونه په کارولو سره تایید شوي وي acks=1
• د مشرتابه هر ډول ناپاک لیږد، دا د ISR څخه بهر پیروانو ته، حتی سره acks = ټول
• د زوکیپر څخه مشر جلا کول که چیرې د پیغامونو کارولو تصدیق شوی وي acks=1
• د مشر بشپړ انزوا چې دمخه یې د ISR ډله ځان ته راټیټه کړې ده. ټول پیغامونه به ورک شي، حتی acks = ټول. دا یوازې ریښتیا ده که چیرې min.insync.replicas=1.
• د ټولو ویشلو نوډونو په ورته وخت کې ناکامي. ځکه چې پیغامونه د حافظې څخه منل شوي ، ځینې ممکن لاهم ډیسک ته ونه لیکل شي. د سرورونو ریبوټ کولو وروسته ، ځینې پیغامونه ممکن ورک وي.

د مشرتابه ناپاک لیږدونه یا د دوی د منع کولو یا لږترلږه دوه بې ځایه کیدو ډاډ ترلاسه کولو څخه مخنیوی کیدی شي. ترټولو دوامدار ترتیب یو ترکیب دی acks = ټول и min.insync.replicas له ۷ څخه زیات

د RabbitMQ او کافکا د اعتبار مستقیم پرتله کول

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

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

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