ڇا اهڙي وڏي ڪمپني کي مجبور ڪري سگهي ٿو Lamoda، هڪ منظم عمل سان ۽ ڪيترن ئي هڪٻئي سان ڳنڍيل خدمتن سان، پنهنجي طريقي سان خاص طور تي تبديل ڪرڻ لاء؟ حوصلا مڪمل طور تي مختلف ٿي سگهن ٿا: قانون سازي کان وٺي سڀني پروگرامرز ۾ موروثي تجربو ڪرڻ جي خواهش تائين.
پر هن جو مطلب اهو ناهي ته توهان اضافي فائدن تي شمار نٿا ڪري سگهو. سرجي زائيڪا توهان کي ٻڌائيندو ته توهان واقعي ڇا کٽي سگهو ٿا جيڪڏهن توهان ڪافڪا تي واقعن تي هلندڙ API لاڳو ڪريو (). اتي به ضرور وڏي شاٽ ۽ دلچسپ دريافتن جي باري ۾ ڳالهائي ويندي - تجربو انھن کان سواء نه ٿا ڪري سگهو.
ڊسڪليمر: ھي آرٽيڪل ھڪڙي ملاقات جي مواد تي ٻڌل آھي جيڪا سرجي نومبر 2018 ۾ HighLoad ++ تي منعقد ڪئي وئي. ڪافڪا سان ڪم ڪرڻ جو لامودا جي لائيو تجربو ٻڌندڙن کي متوجه ڪيو شيڊول تي ٻين رپورٽن کان گهٽ ناهي. اسان سمجهون ٿا ته هي هڪ بهترين مثال آهي ان حقيقت جو ته توهان هميشه هڪ جهڙا ماڻهو ڳولي سگهو ٿا ۽ ڪرڻ گهرجي، ۽ HighLoad++ جا منتظمين ان لاءِ سازگار ماحول پيدا ڪرڻ جي ڪوشش ڪندا رهندا.
عمل جي باري ۾
لامودا هڪ وڏو اي ڪامرس پليٽ فارم آهي جنهن جو پنهنجو رابطو مرڪز، ترسيل سروس (۽ ڪيترائي ساٿي)، هڪ فوٽو اسٽوڊيو، هڪ وڏو گودام، ۽ اهو سڀ ڪجهه پنهنجي سافٽ ويئر تي هلندو آهي. ادائگي جا ڪيترائي طريقا آھن، b2b ڀائيوار جيڪي استعمال ڪري سگھن ٿا انھن مان ڪجھ يا سڀ خدمتون ۽ ڄاڻڻ چاھين ٿا تازه ترين معلومات پنھنجي پروڊڪٽس تي. ان کان سواء، Lamoda روسي فيڊريشن کان سواء ٽن ملڪن ۾ هلندي آهي ۽ اتي هر شيء ٿورو مختلف آهي. مجموعي طور تي، نئين آرڊر کي ترتيب ڏيڻ لاء سؤ کان وڌيڪ طريقا آهن، جن کي پنهنجي طريقي سان عمل ڪيو وڃي. اهو سڀ ڪجهه ڪيترن ئي خدمتن جي مدد سان ڪم ڪري ٿو جيڪي ڪڏهن ڪڏهن غير واضح طريقن سان گفتگو ڪن ٿيون. اتي پڻ هڪ مرڪزي نظام آهي جنهن جي بنيادي ذميواري آرڊر اسٽيٽس آهي. اسان هن کي BOB سڏين ٿا، مان هن سان گڏ ڪم ڪريان ٿو.
واپسي وارو اوزار واقعن تي ٻڌل API سان
واقعن تي ٻڌل لفظ ڪافي ڳنڀير آهي؛ ٿورو اڳتي اسين وڌيڪ تفصيل سان بيان ڪنداسين ته ان مان ڇا مراد آهي. مان ان حوالي سان شروع ڪندس جنهن ۾ اسان ڪافڪا ۾ واقعن تي ٻڌل API طريقي جي ڪوشش ڪرڻ جو فيصلو ڪيو.
ڪنهن به دڪان ۾، آرڊر کان علاوه جن لاءِ گراهڪ ادا ڪندا آهن، اهڙا وقت هوندا آهن جڏهن اسٽور کي رقم واپس ڪرڻي پوندي آهي ڇاڪاڻ ته پراڊڪٽ ڪسٽمر لاءِ مناسب نه هو. اھو ھڪڙو نسبتا مختصر عمل آھي: اسان معلومات کي واضح ڪريون ٿا، جيڪڏھن ضروري ھجي، ۽ پئسا منتقل ڪريو.
پر قانون سازي ۾ تبديلين جي ڪري واپسي وڌيڪ پيچيده ٿي وئي، ۽ اسان کي ان لاءِ الڳ مائڪرو سروس لاڳو ڪرڻي هئي.
اسان جي حوصلا افزائي:
- قانون FZ-54 - مختصر ۾، قانون هر مالياتي ٽرانزيڪشن جي باري ۾ ٽيڪس آفيس کي رپورٽ ڪرڻ جي ضرورت آهي، اها واپسي هجي يا هڪ رسيد، چند منٽن جي ڪافي مختصر SLA اندر. اسان، هڪ اي ڪامرس ڪمپني جي طور تي، تمام گهڻو آپريشن ڪندا آهيون. تخنيقي طور تي، هن جو مطلب آهي نئين ذميواري (۽ انهي ڪري هڪ نئين خدمت) ۽ سڀني ملوث سسٽم ۾ بهتري.
- BOB تقسيم BOB کي وڏي تعداد ۾ غير بنيادي ذميوارين کان آزاد ڪرڻ ۽ ان جي مجموعي پيچيدگي کي گهٽائڻ لاءِ ڪمپني جو هڪ اندروني منصوبو آهي.
هي خاڪو ڏيکاري ٿو مکيه Lamoda سسٽم. هاڻي انهن مان گهڻا وڌيڪ آهن 5-10 microservices جو هڪ ڪنسٽرليشن، هڪ سُرندڙ مونولٿ جي چوڌاري. اهي آهستي آهستي وڌي رهيا آهن، پر اسان ڪوشش ڪري رهيا آهيون ته انهن کي ننڍو ڪريون، ڇاڪاڻ ته وچ ۾ چونڊيل ٽڪرا لڳائڻ خوفناڪ آهي - اسان ان کي گرڻ جي اجازت نٿا ڏئي سگهون. اسان سڀني مٽاسٽا (تير) محفوظ ڪرڻ تي مجبور آهيون ۽ ان حقيقت کي نظر ۾ رکون ٿا ته انهن مان ڪو به دستياب نه ٿي سگهي.
BOB ۾ پڻ ڪافي مٽا سٽا آھن: ادائگي جا نظام، ترسيل سسٽم، نوٽيفڪيشن سسٽم وغيره.
ٽيڪنيڪل طور تي BOB آهي:
- ~ 150k لائينون ڪوڊ + ~ 100k ٽيسٽ جون لائينون؛
- php7.2 + Zend 1 ۽ Symfony اجزاء 3؛
- >100 APIs ۽ ~ 50 ٻاهرئين انضمام؛
- 4 ملڪ پنھنجي ڪاروباري منطق سان.
BOB کي ترتيب ڏيڻ مهانگو ۽ ڏکوئيندڙ آهي، ڪوڊ ۽ مسئلن جو مقدار اهو حل ڪري ٿو ته ڪو به اهو سڀ ڪجهه پنهنجي سر ۾ وجهي نٿو سگهي. عام طور تي، ان کي آسان ڪرڻ جا ڪيترائي سبب آهن.
واپسي جو عمل
شروعات ۾، ٻه سسٽم عمل ۾ شامل آهن: BOB ۽ ادائگي. هاڻي ٻه وڌيڪ ظاهر ٿيندا آهن:
- مالياتي سروس، جيڪا مالياتي ۽ خارجي خدمتن سان رابطي جي مسئلن جو خيال رکندي.
- رقم جي واپسي جو اوزار، جنهن ۾ صرف نوان مٽاسٽا شامل آهن جيئن ته BOB کي ڦهلائڻ نه گهرجي.
هاڻي اهو عمل هن طرح نظر اچي ٿو:
- BOB واپسي جي درخواست وصول ڪري ٿي.
- BOB هن ريفنڊ ٽول بابت ڳالهائي ٿو.
- واپسي وارو اوزار ادائگي کي ٻڌائي ٿو: "پئسا واپس ڪريو."
- ادائگي رقم واپس ڪري ٿي.
- واپسي وارو اوزار ۽ BOB هڪ ٻئي سان اسٽيٽس کي هم وقت سازي ڪن ٿا، ڇاڪاڻ ته هن وقت ٻنهي کي ضرورت آهي. اسان اڃا تائين مڪمل طور تي واپسي واري ٽول تي سوئچ ڪرڻ لاءِ تيار نه آهيون، ڇو ته BOB وٽ هڪ UI آهي، اڪائونٽنگ لاءِ رپورٽون، ۽ عام طور تي تمام گهڻو ڊيٽا آهي جيڪو ايترو آسانيءَ سان منتقل نٿو ڪري سگهجي. توهان کي ٻه ڪرسي تي ويهڻو پوندو.
- ماليات جي درخواست پري وڃي ٿي.
نتيجي طور، اسان ڪافڪا تي هڪ قسم جي ايونٽ بس ٺاهي - ايونٽ بس، جنهن تي هر شيء شروع ٿي. هير، هاڻي اسان وٽ ناڪامي جو هڪ واحد نقطو آهي (طنز).
نفعو ۽ نقصان بلڪل واضح آهن. اسان هڪ بس ٺاهيو، جنهن جو مطلب آهي ته هاڻي سڀ خدمتون ان تي منحصر آهن. هي ڊزائن کي آسان بڻائي ٿو، پر سسٽم ۾ ناڪامي جو هڪ واحد نقطو متعارف ڪرايو. ڪافڪا حادثو ٿيندو، عمل بند ٿي ويندو.
ڇا آهي واقعن تي ٻڌل API
ھن سوال جو ھڪڙو سٺو جواب آھي رپورٽ ۾ مارٽن فولر (GOTO 2017) .
مختصر طور تي اسان ڇا ڪيو:
- سڀني هم وقت سازي جي بدلي کي ختم ڪريو ذريعي واقعن جو ذخيرو. نيٽ ورڪ تي اسٽيٽس جي تبديلي جي باري ۾ هر دلچسپي رکندڙ صارف کي آگاهي ڏيڻ بدران، اسان هڪ واقعو لکون ٿا اسٽيٽس جي تبديلي بابت هڪ سينٽرلائيزڊ اسٽوريج ۾، ۽ موضوع ۾ دلچسپي رکندڙ صارف هر شي کي پڙهي ٿو جيڪو اتان ظاهر ٿئي ٿو.
- هن معاملي ۾ واقعو هڪ نوٽيفڪيشن آهي (اطلاعات) ته ڪجهه تبديل ٿي چڪو آهي. مثال طور، آرڊر جي صورتحال تبديل ٿي وئي آهي. هڪ صارف جيڪو ڪجهه ڊيٽا ۾ دلچسپي رکي ٿو ان سان گڏ اسٽيٽس جي تبديلي جيڪا نوٽيفڪيشن ۾ شامل نه آهي ان جي حيثيت پاڻ کي ڳولي سگهي ٿو.
- وڌ ۾ وڌ آپشن آهي مڪمل ايونٽ سورسنگ، رياست جي منتقلي, جنهن واقعي ۾ پروسيسنگ لاءِ ضروري سموري معلومات شامل آهي: اها ڪٿان آئي ۽ ڪهڙي حيثيت ۾ وئي، ڊيٽا ڪيئن بدلجي وئي، وغيره. صرف سوال اهو آهي ته فزيبلٽي ۽ معلومات جو مقدار جيڪو توهان ذخيرو ڪري سگهو ٿا.
ريفنڊ ٽول جي لانچ جي حصي جي طور تي، اسان ٽيون آپشن استعمال ڪيو. اهو آسان ٿيل واقعي جي پروسيسنگ کان وٺي تفصيلي ڄاڻ ڪڍڻ جي ڪا ضرورت ناهي، انهي سان گڏ اهو منظر ختم ڪري ٿو جتي هر نئون واقعو واضح ڪري ٿو ته صارفين کان درخواستون حاصل ڪريو.
واپسي جي اوزار جي خدمت لوڊ نه ٿيوتنهنڪري ڪافڪا وٽ قلم جو ذائقو ضرورت کان وڌيڪ آهي. مان نه ٿو سمجهان ته جيڪڏهن واپسي جي خدمت هڪ اعلي لوڊ منصوبو بڻجي وئي، ڪاروبار خوش ٿيندو.
Async جي بدلي AS IS
هم وقت سازي جي بدلي لاء، PHP ڊپارٽمينٽ عام طور تي استعمال ڪري ٿو RabbitMQ. اسان درخواست لاء ڊيٽا گڏ ڪيو، ان کي قطار ۾ رکون، ۽ ساڳئي خدمت جي صارف ان کي پڙهي ۽ موڪليو (يا نه موڪليو). خود API لاءِ، لامودا فعال طور تي سوگر استعمال ڪري ٿو. اسان ھڪڙو API ٺاھيون ٿا، ان کي سوگر ۾ بيان ڪريو، ۽ ڪلائنٽ ۽ سرور ڪوڊ ٺاھيو. اسان پڻ استعمال ڪريون ٿا ٿورڙو وڌايل JSON RPC 2.0.
ڪجھ هنڌن تي اي ايس بي بسون استعمال ڪيون وينديون آهن، ڪجهه فعال ايم ڪيو تي رهن ٿا، پر عام طور تي، RabbitMQ - معياري.
Async مٽا سٽا TO BE
جڏهن ايونٽس-بس ذريعي مٽاسٽا کي ڊزائين ڪرڻ، هڪ قياس ڳولي سگهجي ٿو. اسان ساڳئي طرح بيان ڪريون ٿا مستقبل جي ڊيٽا مٽائڻ واري واقعي جي جوڙجڪ جي وضاحت ذريعي. yaml فارميٽ، اسان کي ڪوڊ جي پيدائش پاڻ کي ڪرڻو پوندو، جنريٽر وضاحتن جي مطابق ڊي ٽي اوز ٺاهي ٿو ۽ ڪلائنٽ ۽ سرورز کي سيکاريندو آهي انهن سان ڪم ڪرڻ. نسل ٻن ٻولين ۾ وڃي ٿي - گولنگ ۽ php. هي مدد ڪري ٿو لائبريرين کي مسلسل رکڻ ۾. جنريٽر گولانگ ۾ لکيل آهي، ان ڪري ان جو نالو گوگي پيو.
ڪافڪا تي ايونٽ سورسنگ هڪ عام شيءِ آهي. ڪافڪا ڪنفلوئنٽ جي مکيه انٽرنيشنل ورزن مان هڪ حل آهي، اتي آهي , اسان جي ڊومين ڀائرن Zalando کان هڪ حل. اسان جي وينلا ڪافڪا سان شروع ڪرڻ جي حوصلا افزائي - ان جو مطلب اهو آهي ته حل کي آزاد ڇڏي ڏيو جيستائين اسان آخرڪار اهو فيصلو ڪريون ته ڇا اسان ان کي هر جڳهه استعمال ڪنداسين، ۽ پڻ پنهنجو پاڻ کي هلائڻ ۽ بهتري لاءِ ڪمرو ڇڏي ڏيو: اسان چاهيون ٿا اسان جي مدد لاءِ JSON RPC 2.0، ٻن ٻولين لاءِ جنريٽر ۽ اچو ته ڏسون ٻيو ڇا.
اها ستم ظريفي آهي ته اهڙي خوشيءَ واري حالت ۾ به، جڏهن ڪو اهڙو ڪاروبار هوندو آهي، جيڪو تقريباً ساڳيو حل تيار ڪيو ويندو آهي، Zalando، اسان ان کي اثرائتو استعمال نٿا ڪري سگهون.
لانچ تي تعميراتي نمونو هن ريت آهي: اسان سڌو سنئون ڪافڪا کان پڙهون ٿا، پر صرف واقعن-بس ذريعي لکندا آهيون. ڪافڪا ۾ پڙهڻ لاءِ تمام گهڻو تيار آهي: بروکرز، بيلنسرز، ۽ اهو گهٽ يا گهٽ افقي اسڪيلنگ لاءِ تيار آهي، مان هن کي رکڻ چاهيان ٿو. اسان هڪ گيٽ وي عرف واقعن-بس ذريعي رڪارڊنگ مڪمل ڪرڻ چاهيون ٿا، ۽ هتي ئي آهي.
واقعا- بس
يا هڪ واقعو بس. اهو صرف هڪ بي رياست http گيٽ وي آهي، جيڪو ڪيترن ئي اهم ڪردارن تي وٺندو آهي:
- پيداوار جي تصديق - اسان چيڪ ڪريون ٿا ته واقعا اسان جي وضاحتن سان ملن ٿا.
- ايونٽ ماسٽر سسٽم، اهو آهي، اهو ڪمپني ۾ بنيادي ۽ واحد سسٽم آهي جيڪو ان سوال جو جواب ڏئي ٿو ته ڪهڙن واقعن سان گڏ تعميرات صحيح سمجهي رهيا آهن. تصديق ۾ صرف ڊيٽا جا قسم ۽ اينيم شامل آهن سختي سان مواد کي بيان ڪرڻ لاء.
- هاش فنڪشن شارڊنگ لاءِ - ڪافڪا پيغام جو ڍانچو ڪيئي قدر آهي ۽ هيش آف ڪيئي استعمال ڪندي حساب ڪيو ويندو آهي ته ان کي ڪٿي رکڻو آهي.
ڇو
اسان هڪ وڏي ڪمپني ۾ ڪم ڪريون ٿا هڪ منظم عمل سان. ڇو ڪا شيء تبديل؟ هي هڪ تجربو آهي، ۽ اسان کي ڪيترائي فائدا حاصل ڪرڻ جي اميد آهي.
1:n+1 مٽا سٽا (هڪ کان گھڻا)
Kafka نئين صارفين کي API سان ڳنڍڻ تمام آسان بڻائي ٿو.
اچو ته چئو ته توهان وٽ هڪ ڊاريڪٽري آهي جيڪا توهان کي هڪ ئي وقت ۾ ڪيترن ئي سسٽم ۾ (۽ ڪجهه نئين ۾) تازه ڪاري ڪرڻ جي ضرورت آهي. اڳي، اسان هڪ بنڊل ايجاد ڪيو جيڪو لاڳو ڪيو سيٽ-API، ۽ ماسٽر سسٽم کي صارف جي پتي جي ڄاڻ ڏني وئي. هاڻي ماسٽر سسٽم موضوع ڏانهن تازه ڪاري موڪلي ٿو، ۽ هرڪو جيڪو دلچسپي رکي ٿو اهو پڙهي ٿو. ھڪڙو نئون سسٽم ظاهر ٿيو آھي - اسان ان کي موضوع لاء سائن اپ ڪيو آھي. ها، پڻ بنڊل، پر آسان.
رقم جي واپسي واري اوزار جي صورت ۾، جيڪو BOB جو هڪ ٽڪرو آهي، اهو اسان لاءِ آسان آهي ته انهن کي ڪافڪا جي ذريعي هم وقت سازي رکون. ادائگي جو چوڻ آهي ته رقم واپس ڪئي وئي: BOB، RT کي ان بابت معلوم ٿيو، انهن جي اسٽيٽس کي تبديل ڪيو، مالياتي سروس ان بابت معلوم ڪيو ۽ هڪ چيڪ جاري ڪيو.
اسان وٽ هڪ متحد نوٽيفڪيشن سروس ٺاهڻ جو منصوبو آهي جيڪو ڪلائنٽ کي خبر ڏيندو ته هن جي آرڊر / واپسي جي حوالي سان. هاڻي اها ذميواري نظام جي وچ ۾ پکڙيل آهي. اهو اسان لاءِ ڪافي هوندو ته نوٽيفڪيشن سروس کي سيکاريون ته ڪافڪا کان لاڳاپيل معلومات حاصل ڪري ۽ ان جو جواب ڏيو (۽ انهن اطلاعن کي ٻين سسٽم ۾ غير فعال ڪريون). ڪابه نئين سڌي مٽاسٽا جي ضرورت نه هوندي.
ڊيٽا تي ڀاڙڻ
سسٽم جي وچ ۾ معلومات شفاف ٿي ويندي آهي - ڪابه پرواهه ناهي ته توهان وٽ ڪهڙي به "خونري ڪاروبار" آهي ۽ توهان جي پٺتي پيل ڪيترو به ڀريل آهي. لامودا وٽ ڊيٽا اينالائيٽڪس ڊپارٽمينٽ آهي جيڪو سسٽم مان ڊيٽا گڏ ڪري ٿو ۽ ان کي ٻيهر استعمال جي قابل فارم ۾ رکي ٿو، ٻئي ڪاروبار ۽ ذهين سسٽم لاءِ. ڪافڪا توهان کي جلدي انهن کي تمام گهڻو ڊيٽا ڏيڻ جي اجازت ڏئي ٿو ۽ انهي معلومات جي وهڪري کي تاريخ تائين رکي ٿو.
ريپليڪشن لاگ
پڙهڻ کان پوءِ پيغام غائب نه ٿيندا آهن، جيئن RabbitMQ ۾. جڏهن هڪ واقعو پروسيسنگ لاءِ ڪافي معلومات تي مشتمل هوندو آهي، اسان وٽ اعتراض ۾ تازين تبديلين جي تاريخ هوندي آهي، ۽، جيڪڏهن گهربل هجي، انهن تبديلين کي لاڳو ڪرڻ جي صلاحيت.
ريپليڪشن لاگ جي اسٽوريج جي مدت جو دارومدار هن موضوع تي لکڻ جي شدت تي آهي؛ ڪافڪا توهان کي اجازت ڏئي ٿو لچڪدار طور تي اسٽوريج جي وقت ۽ ڊيٽا جي مقدار تي حدون مقرر ڪرڻ. شديد عنوانن لاءِ، اهو ضروري آهي ته سڀني صارفن وٽ معلومات پڙهڻ لاءِ وقت هجي ان جي غائب ٿيڻ کان اڳ، جيتوڻيڪ مختصر مدت جي غير فعال ٿيڻ جي صورت ۾. اهو عام طور تي ڊيٽا کي ذخيرو ڪرڻ ممڪن آهي ڏينهن جا يونٽ، جيڪو سپورٽ لاءِ ڪافي آهي.
اڳيون، دستاويزن جو ٿورڙو بيان، انهن لاءِ جيڪي ڪافڪا کان واقف نه آهن (تصوير پڻ دستاويز مان آهي)
AMQP جون قطارون آهن: اسان صارف لاءِ قطار ۾ پيغام لکون ٿا. عام طور تي، ھڪڙي قطار ھڪڙي سسٽم طرفان ھڪڙي ڪاروباري منطق سان عمل ڪيو ويندو آھي. جيڪڏهن توهان کي ڪيترن ئي سسٽمن کي اطلاع ڏيڻ جي ضرورت آهي، ته توهان ايپليڪيشن کي سيکاري سگهو ٿا ڪيترن ئي قطارن ڏانهن لکڻ يا مٽائي ترتيب ڏيڻ فين آئوٽ ميڪانيزم سان، جيڪو انهن کي پاڻ کي ڪلون ڪري ٿو.
ڪافڪا وٽ به ساڳيو خلاصو آهي موضوع، جنهن ۾ توهان پيغام لکندا آهيو، پر اهي پڙهڻ کان پوء غائب نه ٿيندا آهن. ڊفالٽ طور، جڏهن توهان ڪافڪا سان ڳنڍيندا آهيو، توهان سڀ پيغام وصول ڪندا آهيو ۽ توهان وٽ محفوظ ڪرڻ جو اختيار هوندو آهي جتي توهان ڇڏيو هو. اهو آهي، توهان ترتيب سان پڙهي سگهو ٿا، توهان شايد پيغام کي پڙهيل طور نشان نه لڳائي سگهو ٿا، پر id کي محفوظ ڪريو جنهن کان پوء توهان پڙهڻ جاري رکي سگهو ٿا. Id جنهن تي توهان آباد ٿيا آهيو ان کي آفسيٽ چئبو آهي، ۽ ميکانيزم ڪمٽ آف سيٽ آهي.
تنهن ڪري، مختلف منطق لاڳو ڪري سگهجي ٿو. مثال طور، اسان وٽ مختلف ملڪن لاء 4 مثالن ۾ BOB آهي - لامودا روس، قزاقستان، يوڪرين، بيلاروس ۾ آهي. جيئن ته اهي الڳ الڳ مقرر ڪيا ويا آهن، انهن وٽ ٿورڙي مختلف ترتيب ۽ انهن جي پنهنجي ڪاروباري منطق آهي. اسان پيغام ۾ اشارو ڪريون ٿا ته اهو ڪهڙو ملڪ آهي. هر ملڪ ۾ هر BOB صارف هڪ مختلف گروپ آئي ڊي سان پڙهي ٿو، ۽ جيڪڏهن پيغام انهن تي لاڳو نٿو ٿئي، اهي ان کي ڇڏيندا آهن، يعني. فوري طور تي ڪم ڪري ٿو آفسيٽ +1. جيڪڏهن اهو ساڳيو موضوع اسان جي ادائگي جي خدمت پاران پڙهيو ويو آهي، ته پوء اهو هڪ الڳ گروپ سان ڪري ٿو، ۽ تنهن ڪري آف سيٽس هڪ ٻئي کي نه ٿا ڪن.
واقعي جي گهرج:
- ڊيٽا مڪمل. مان چاهيان ٿو ته واقعي ۾ ڪافي ڊيٽا هجي ته جيئن ان کي پروسيس ڪري سگهجي.
- ايمانداري. اسان ايونٽس-بس کي تصديق ڪريون ٿا ته واقعي هڪجهڙائي آهي ۽ اهو ان تي عمل ڪري سگهي ٿو.
- آرڊر اهم آهي. واپسي جي صورت ۾، اسان کي تاريخ سان ڪم ڪرڻو پوندو. اطلاعن سان، آرڊر اهم نه آهي، جيڪڏهن اهي هڪجهڙائي وارا اطلاع آهن، اي ميل ساڳيو هوندو، قطع نظر ته آرڊر پهريون ڀيرو آيو. واپسي جي صورت ۾، هڪ واضح عمل آهي؛ جيڪڏهن اسان آرڊر تبديل ڪريون ٿا، استثنا پيدا ٿيندا، واپسي پيدا نه ٿيندي يا عمل نه ڪيو ويندو - اسان هڪ مختلف حيثيت ۾ ختم ڪنداسين.
- تسلسل. اسان وٽ ھڪڙو اسٽور آھي، ۽ ھاڻي اسان اي پي آئي جي بدران واقعا ٺاھيون ٿا. اسان کي نئين واقعن بابت معلومات کي جلدي ۽ سستي طور تي منتقل ڪرڻ لاء هڪ طريقي جي ضرورت آهي ۽ موجوده واقعن ۾ تبديلين کي اسان جي خدمتن ڏانهن. اهو حاصل ڪيو ويو آهي هڪ عام وضاحت ذريعي هڪ الڳ گٽ مخزن ۽ ڪوڊ جنريٽر ۾. تنهن ڪري، مختلف خدمتن ۾ ڪلائنٽ ۽ سرورز هموار ٿيل آهن.
ڪافڪا لامودا ۾
اسان وٽ ٽي ڪافڪا تنصيب آهن:
- لاگز؛
- آر ۽ ڊي؛
- واقعا- بس.
اڄ اسان صرف آخري نقطي بابت ڳالهائي رهيا آهيون. واقعن-بس تي، اسان وٽ تمام وڏا تنصيب نه آهن - 3 بروکرز (سرور) ۽ صرف 27 موضوع. ضابطي جي طور تي، ھڪڙو موضوع ھڪڙو عمل آھي. پر هي هڪ نفيس نقطو آهي، ۽ اسان ان تي هاڻي رابطو ڪنداسين.
مٿي آر پي ايس گراف آهي. واپسي جي عمل کي فيروزي لائن سان نشان لڳايو ويو آهي (ها، ايڪس محور تي هڪ)، ۽ گلابي لائن مواد جي تازه ڪاري جو عمل آهي.
Lamoda فهرست لکين پراڊڪٽس تي مشتمل آهي، ۽ ڊيٽا هر وقت اپڊيٽ ڪئي ويندي آهي. ڪجهه مجموعا فيشن کان ٻاهر نڪرندا آهن، انهن کي تبديل ڪرڻ لاء نوان جاري ڪيا ويا آهن، ۽ نوان ماڊل مسلسل فهرست ۾ ظاهر ٿيندا آهن. اسان اڳڪٿي ڪرڻ جي ڪوشش ڪندا آهيون ته سڀاڻي اسان جي گراهڪن لاءِ ڇا دلچسپ هوندو، تنهنڪري اسان مسلسل نيون شيون خريد ڪندا آهيون، انهن کي فوٽو ڪڍندا آهيون ۽ ڊسپلي ڪيس کي اپڊيٽ ڪندا آهيون.
گلابي چوٽيون پراڊڪٽ اپڊيٽ آهن، اهو آهي، مصنوعات ۾ تبديليون. اهو ڏسي سگهجي ٿو ته ماڻهو تصويرون ڪڍيا، تصويرون ڪڍيا، ۽ پوء ٻيهر! - واقعن جو هڪ پيڪ لوڊ ڪيو.
لامودا واقعا ڪيس استعمال ڪن ٿا
اسان هيٺ ڏنل عملن لاء تعمير ٿيل فن تعمير استعمال ڪندا آهيون:
- واپسي جي صورتحال ٽريڪنگ: سڀني ملوث سسٽم کان ڪال-ٽو-ايڪشن ۽ اسٽيٽس ٽريڪنگ. ادائگي، حالت، مالياتي، اطلاع. هتي اسان طريقي جي جانچ ڪئي، اوزار ٺاهيا، سڀئي ڪيڙا گڏ ڪيا، دستاويز لکيا ۽ پنهنجن ساٿين کي ٻڌايو ته ان کي ڪيئن استعمال ڪجي.
- پراڊڪٽ ڪارڊ اپڊيٽ ڪرڻ: ترتيب، ميٽا ڊيٽا، خاصيتون. ھڪڙو سسٽم پڙھي ٿو (جيڪو ڏيکاري ٿو)، ۽ ڪيترائي لکن ٿا.
- اي ميل، پش ۽ ايس ايم ايس: آرڊر گڏ ڪيو ويو آهي، آرڊر اچي چڪو آهي، واپسي قبول ڪئي وئي آهي، وغيره، انهن مان گهڻا آهن.
- اسٽاڪ، گودام جي تجديد - شين جي مقدار جي تازه ڪاري، صرف نمبر: گودام تي پهچڻ، واپسي. اهو ضروري آهي ته سامان محفوظ ڪرڻ سان لاڳاپيل سڀئي سسٽم تمام موجوده ڊيٽا سان هلن. في الحال، اسٽاڪ اپڊيٽ سسٽم ڪافي پيچيده آهي؛ ڪافڪا ان کي آسان بڻائي ڇڏيندو.
- ڊيٽا تجزيه (آر اينڊ ڊي ڊپارٽمينٽ)، ايم ايل اوزار، تجزياتي، شماريات. اسان چاهيون ٿا ته معلومات شفاف هجي - ڪافڪا ان لاءِ مناسب آهي.
ھاڻي وڌيڪ دلچسپ حصو وڏن جھازن ۽ دلچسپ دريافتن بابت جيڪي گذريل ڇھن مھينن ۾ ٿيا آھن.
ڊيزائن جا مسئلا
اچو ته چئو ته اسان هڪ نئين شيء ڪرڻ چاهيون ٿا - مثال طور، سڄي پهچائڻ واري عمل کي ڪافڪا ڏانهن منتقل ڪريو. هاڻي عمل جو حصو BOB ۾ آرڊر پروسيسنگ ۾ لاڳو ڪيو ويو آهي. ترسيل سروس ڏانهن آرڊر جي منتقلي جي پويان هڪ اسٽيٽس ماڊل آهي، هڪ وچولي گودام ڏانهن حرڪت، وغيره. هتي هڪ مڪمل monolith آهي، جيتوڻيڪ ٻه، گڏوگڏ APIs جو هڪ گروپ پهچائڻ لاء وقف آهي. اهي ترسيل بابت گهڻو ڄاڻن ٿا.
لڳي ٿو ته اهي ساڳيا علائقا آهن، پر BOB ۾ آرڊر پروسيسنگ ۽ شپنگ سسٽم جون حالتون مختلف آهن. مثال طور، ڪجهه ڪوريئر سروسز وچولي حالتون نه موڪليندا آهن، پر صرف آخري آهن: "ترسيل" يا "گم ٿيل". ٻيا، ان جي ابتڙ، سامان جي حرڪت بابت وڏي تفصيل سان رپورٽ ڪن ٿا. هر ڪنهن جا پنهنجا پنهنجا صحيح ضابطا آهن: ڪجهه لاءِ، اي ميل صحيح آهي، جنهن جو مطلب آهي ته ان تي عمل ڪيو ويندو؛ ٻين لاءِ اهو صحيح ناهي، پر آرڊر تي عمل ڪيو ويندو ڇو ته اتي رابطي لاءِ هڪ فون نمبر آهي، ۽ ڪو ماڻهو چوندو ته اهڙي آرڊر تي عمل نه ڪيو ويندو.
ڊيٽا وهڪرو
ڪافڪا جي صورت ۾، ڊيٽا جي وهڪري کي منظم ڪرڻ جو سوال پيدا ٿئي ٿو. هن ڪم ۾ ڪيترن ئي نقطن جي بنياد تي حڪمت عملي چونڊڻ شامل آهي؛ اچو ته انهن سڀني جي ذريعي وڃو.
هڪ موضوع ۾ يا مختلف موضوعن ۾؟
اسان وٽ هڪ واقعي جي وضاحت آهي. BOB ۾ اسان لکون ٿا ته اهڙي ۽ اهڙي آرڊر کي پهچائڻ جي ضرورت آهي، ۽ اشارو ڏيو: آرڊر نمبر، ان جي جوڙجڪ، ڪجهه SKUs ۽ بار ڪوڊ، وغيره. جڏهن سامان گودام تي پهچندو، ترسيل حاصل ڪرڻ جي قابل هوندو اسٽيٽس، ٽائيم اسٽيمپ ۽ هر شيء جيڪا گهربل هجي. پر پوءِ اسان BOB ۾ ھن ڊيٽا تي تازه ڪاريون حاصل ڪرڻ چاھيون ٿا. اسان وٽ ترسيل کان ڊيٽا حاصل ڪرڻ جو هڪ ريورس عمل آهي. ڇا اهو ساڳيو واقعو آهي؟ يا هي هڪ الڳ مٽا سٽا آهي جيڪو پنهنجي موضوع جو مستحق آهي؟
گهڻو ڪري، اهي بلڪل هڪجهڙا هوندا، ۽ هڪ موضوع ٺاهڻ جو لالچ بي بنياد نه آهي، ڇاڪاڻ ته هڪ الڳ موضوع جو مطلب آهي الڳ صارفين، الڳ ترتيب، انهن سڀني جو هڪ الڳ نسل. پر حقيقت ناهي.
نئون ميدان يا نئون واقعو؟
پر جيڪڏهن توهان ساڳئي واقعن کي استعمال ڪندا آهيو، پوء هڪ ٻيو مسئلو پيدا ٿئي ٿو. مثال طور، نه سڀئي ترسيل سسٽم اهڙي قسم جي ڊي ٽي او ٺاهي سگهندا آهن جيڪا BOB ٺاهي سگهي ٿي. اسان انهن کي آئي ڊي موڪليندا آهيون، پر اهي ان کي محفوظ نه ڪندا آهن ڇو ته انهن کي ان جي ضرورت ناهي، ۽ واقعي جي بس جي عمل کي شروع ڪرڻ جي نقطي نظر کان، هي فيلڊ گهربل آهي.
جيڪڏهن اسان ايونٽ-بس لاءِ هڪ قاعدو متعارف ڪرايون ٿا ته هي فيلڊ گهربل آهي، ته پوءِ اسان BOB ۾ يا شروعاتي ايونٽ هينڊلر ۾ اضافي تصديق جي ضابطن کي مقرر ڪرڻ تي مجبور آهيون. تصديق سڄي خدمت ۾ پکڙجڻ شروع ٿئي ٿي - اهو تمام آسان ناهي.
ٻيو مسئلو وڌندڙ ترقي جي لالچ آهي. اسان کي ٻڌايو ويو آهي ته واقعي ۾ ڪجهه شامل ڪرڻ جي ضرورت آهي، ۽ شايد، جيڪڏهن اسان ان بابت سوچيو ته اهو هڪ الڳ واقعو هجڻ گهرجي. پر اسان جي اسڪيم ۾، هڪ الڳ واقعو هڪ الڳ موضوع آهي. هڪ الڳ موضوع اهو سڄو عمل آهي جيڪو مون مٿي بيان ڪيو آهي. ڊولپر کي آزمايو ويو آهي ته صرف JSON اسڪيما ۾ ٻي فيلڊ شامل ڪري ۽ ان کي ٻيهر پيدا ڪري.
واپسي جي صورت ۾، اسان اڌ سال ۾ واقعن جي واقعن تي پهچي ويا. اسان وٽ ھڪڙو ميٽا-ايونٽ آھي جنھن کي ريفنڊ اپڊيٽ سڏيو ويندو آھي، جنھن ۾ ھڪڙي قسم جي فيلڊ ھئي جيڪا بيان ڪري ٿي ته ھي تازه ڪاري اصل ۾ ڇا آھي. انهي جي ڪري، اسان وٽ تصديق ڪندڙن سان "شاندار" سوئچز هئا جن اسان کي ٻڌايو ته هن قسم سان هن واقعي جي تصديق ڪيئن ڪجي.
واقعي جو نسخو
ڪافڪا ۾ پيغامن جي تصديق ڪرڻ لاءِ توهان استعمال ڪري سگهو ٿا ، پر ان کي فوري طور تي ان تي رکڻ ۽ Confluent استعمال ڪرڻ ضروري هو. اسان جي صورت ۾، اسان کي نسخي سان محتاط هجڻ گهرجي. اهو هميشه ممڪن نه هوندو ته نقل جي لاگ مان پيغامن کي ٻيهر پڙهڻ ڇاڪاڻ ته ماڊل "کاٻي" آهي. بنيادي طور تي، اهو ظاهر ٿئي ٿو ته نسخن کي تعمير ڪيو وڃي ته جيئن ماڊل پسمانده مطابقت رکندڙ آهي: مثال طور، هڪ فيلڊ کي عارضي طور تي اختياري ٺاهيو. جيڪڏهن اختلاف تمام مضبوط آهن، اسان هڪ نئين موضوع ۾ لکڻ شروع ڪندا آهيون، ۽ ڪلائنٽ کي منتقل ڪندا آهيون جڏهن اهي پراڻي پڙهڻ کي ختم ڪندا.
ورهاڱي جي گارنٽيڊ ريڊنگ آرڊر
ڪافڪا جي اندر جا موضوع ڀاڱن ۾ ورهايل آهن. اهو تمام ضروري ناهي جڏهن اسان ادارن ۽ مٽاسٽا کي ڊزائين ڪري رهيا آهيون، پر اهو ضروري آهي جڏهن اهو فيصلو ڪيو وڃي ته ان کي ڪيئن استعمال ڪجي ۽ ماپ ڪجي.
عام صورت ۾، توهان ڪافڪا ۾ هڪ موضوع لکندا آهيو. ڊفالٽ طور، ھڪڙو ورهاڱي استعمال ڪيو ويندو آھي، ۽ ھن موضوع ۾ سڀ پيغام ان ڏانھن وڃو. ۽ صارف انهن پيغامن کي ترتيب سان پڙهي ٿو. اچو ته هاڻي اسان کي سسٽم کي وڌائڻ جي ضرورت آهي ته جيئن پيغام ٻه مختلف صارفين طرفان پڙهيا وڃن. جيڪڏهن، مثال طور، توهان ايس ايم ايس موڪلي رهيا آهيو، ته پوء توهان ڪافڪا کي هڪ اضافي ورهاڱي ڪرڻ لاء چئي سگهو ٿا، ۽ ڪافڪا پيغامن کي ٻن حصن ۾ ورهائڻ شروع ڪندو - اڌ هتي، اڌ هتي.
ڪافڪا انهن کي ڪيئن ورهائي ٿو؟ هر پيغام ۾ هڪ باڊي آهي (جنهن ۾ اسان JSON ذخيرو ڪندا آهيون) ۽ هڪ ڪنجي. توھان ھيش فنڪشن کي ھن ڪني سان ڳنڍي سگھو ٿا، جيڪو طئي ڪندو ته پيغام ڪھڙي ورهاڱي ۾ ويندو.
اسان جي صورت ۾ رقم جي واپسي سان، اهو ضروري آهي، جيڪڏهن اسان ٻه ورهاڱي وٺون ٿا، پوء هڪ موقعو آهي ته هڪ متوازي صارف پهرين واقعي کان پهريان ٻئي واقعي تي عمل ڪندو ۽ اتي مصيبت هوندي. هيش فنڪشن انهي ڳالهه کي يقيني بڻائي ٿو ته پيغام ساڳئي ڪنجي سان ساڳي ورهاڱي ۾ ختم ٿي وڃن.
ايونٽس بمقابله حڪم
اهو هڪ ٻيو مسئلو آهي جيڪو اسان کي منهن ڏيڻو پيو. واقعو هڪ خاص واقعو آهي: اسان چئون ٿا ته ڪجهه ٿيو آهي ڪٿي (something_happened)، مثال طور، هڪ شئي منسوخ ڪئي وئي يا واپسي ٿي وئي. جيڪڏهن ڪو انهن واقعن کي ٻڌي ٿو، ته پوءِ ”آئٽم منسوخ ٿيل“ جي مطابق، رقم جي واپسي جو ادارو ٺاهيو ويندو، ۽ سيٽ اپ ۾ ڪٿي ڪٿي ”ريفنڊ ٿي ويو“ لکيو ويندو.
پر عام طور تي، جڏهن توهان واقعن کي ترتيب ڏيو ٿا، توهان انهن کي بيڪار لکڻ نٿا چاهيو - توهان ان حقيقت تي ڀاڙيندا آهيو ته ڪو ماڻهو انهن کي پڙهي سگهندو. هتي لکڻ لاءِ هڪ اعليٰ لالچ آهي ته نه ڪجهه_ٿيا (آئيٽم_منسوخ ٿيل، واپسي_ريفنڊ ٿيل)، پر ڪجهه_ڪجهه_شي_ڊون. مثال طور، شيء واپس ڪرڻ لاء تيار آهي.
هڪ پاسي، اهو مشورو ڏئي ٿو ته واقعي ڪيئن استعمال ڪيو ويندو. ٻئي طرف، اهو عام واقعي جي نالي وانگر تمام گهٽ آواز آهي. ان کان سواء، اهو هتي کان پري ناهي do_something حڪم. پر توهان کي ڪا به ضمانت نه آهي ته ڪو ماڻهو هن واقعي کي پڙهي؛ ۽ جيڪڏھن توھان ان کي پڙھو، ته توھان ان کي ڪاميابيءَ سان پڙھو؛ ۽ جيڪڏھن توھان ان کي ڪاميابيءَ سان پڙھو، پوءِ توھان ڪجھ ڪيو، ۽ اھو ڪجھھ ڪامياب ٿيو. جنهن لمحي هڪ واقعو do_something ٿئي ٿو، راءِ ضروري ٿي وڃي ٿي، ۽ اهو هڪ مسئلو آهي.
RabbitMQ ۾ غير مطابقت واري تبادلي ۾، جڏهن توهان پيغام پڙهو ٿا، http ڏانهن وڃو، توهان وٽ هڪ جواب آهي - گهٽ ۾ گهٽ اهو پيغام مليو هو. جڏهن توهان ڪافڪا ڏانهن لکندا آهيو، اتي هڪ پيغام هوندو آهي جيڪو توهان ڪافڪا ڏانهن لکيو هو، پر توهان کي ڪا به خبر ناهي ته اهو ڪيئن عمل ڪيو ويو.
تنهن ڪري، اسان جي معاملي ۾، اسان کي هڪ جوابي واقعو متعارف ڪرائڻو پوندو ۽ مانيٽرنگ قائم ڪرڻ گهرجي ته جيئن جيڪڏهن ايترا واقعا موڪليا وڃن، اهڙي وقت کان پوء ساڳئي تعداد ۾ جوابي واقعا اچن. جيڪڏهن ائين نه ٿيو ته پوءِ لڳي ٿو ته ڪجهه غلط ٿي ويو آهي. مثال طور، جيڪڏهن اسان موڪليو "item_ready_to_refund" واقعي، اسان کي اميد آهي ته هڪ واپسي ٺاهي ويندي، پئسا واپس ڪلائنٽ ڏانهن موٽايو ويندو، ۽ "پيسا_ريفنڊڊ" واقعي اسان ڏانهن موڪليو ويندو. پر اها پڪ ناهي، تنهنڪري نگراني جي ضرورت آهي.
نونسن
اتي ھڪڙو واضح مسئلو آھي: جيڪڏھن توھان ھڪڙي موضوع کان ترتيب وار پڙھندا آھيو، ۽ توھان وٽ ڪجھ خراب پيغام آھي، صارف گر ٿي ويندو، ۽ توھان اڳتي نه وڌندا. توهان کي ضرورت آهي سڀني صارفين کي روڪيو، پڙهڻ جاري رکڻ لاءِ وڌيڪ آفسٽ ڪريو.
اسان ان جي باري ۾ ڄاڻون ٿا، اسان ان تي شمار ڪيو، ۽ اڃا تائين اهو ٿيو. ۽ اهو ٿيو ڇو ته واقعو واقعن جي نقطي نظر کان صحيح هو-بس، واقعو ايپليڪيشن جي تصديق ڪندڙ جي نقطي نظر کان صحيح هو، پر اهو PostgreSQL جي نقطي نظر کان صحيح نه هو، ڇاڪاڻ ته اسان جي هڪ سسٽم ۾ MySQL اڻڄاتل INT سان، ۽ نئين لکت ۾ سسٽم صرف INT سان PostgreSQL هو. هن جو قد ٿورڙو ننڍڙو آهي، ۽ آئي ڊي مناسب نه هئي. سمفوني هڪ استثنا سان مري ويو. اسان، يقينا، استثنا کي پڪڙيو ڇاڪاڻ ته اسان ان تي ڀروسو ڪيو، ۽ هن آفسيٽ کي انجام ڏيڻ وارا هئاسين، پر ان کان اڳ اسان مسئلي جي انسداد کي وڌائڻ چاهيون ٿا، ڇاڪاڻ ته پيغام تي عمل ناڪام ٿي ويو. ھن پروجيڪٽ ۾ شمار ڪندڙ پڻ ڊيٽابيس ۾ آھن، ۽ سمفوني اڳ ۾ ئي ڊيٽابيس سان رابطي کي بند ڪري ڇڏيو آھي، ۽ ٻيو استثنا سڄي عمل کي ختم ڪرڻ جو موقعو ڏيڻ کان سواء ماريو ويو.
خدمت ڪجهه وقت لاء رکيل آهي - خوش قسمت، ڪافڪا سان اهو ايترو خراب ناهي، ڇاڪاڻ ته پيغام رهي ٿو. جڏهن ڪم بحال ٿيو، توهان انهن کي پڙهڻ ختم ڪري سگهو ٿا. اهو آرامده آهي.
ڪافڪا وٽ اوزارن جي ذريعي هڪ صوابديدي آفيسر مقرر ڪرڻ جي صلاحيت آهي. پر هن کي ڪرڻ لاء، توهان کي سڀني صارفين کي روڪڻ جي ضرورت آهي - اسان جي صورت ۾، هڪ الڳ رليز تيار ڪريو جنهن ۾ ڪو به صارف نه هوندو، ٻيهر نوڪريون. پوءِ ڪافڪا ۾ توهان ٽولينگ ذريعي آفسٽ کي شفٽ ڪري سگهو ٿا، ۽ پيغام به ان ذريعي ويندو.
هڪ ٻيو نزاڪت - نقل لاگ بمقابله rdkafka.so - اسان جي منصوبي جي خاصيتن سان لاڳاپيل آهي. اسان PHP استعمال ڪريون ٿا، ۽ PHP ۾، ضابطي جي طور تي، سڀئي لائبريريون ڪافڪا سان rdkafka.so ريپوزٽري ذريعي رابطو ڪن ٿيون، ۽ پوءِ اتي ڪجهه قسم جو لفافي آهي. ٿي سگهي ٿو اهي اسان جون ذاتي مشڪلاتون هجن، پر اهو معلوم ٿيو ته جيڪو ڪجهه اسان اڳ ۾ ئي پڙهيو هو، ان کي ٻيهر پڙهڻ ايترو آسان ناهي. عام طور تي، اتي سافٽ ويئر مسئلا هئا.
ورهاڱي سان ڪم ڪرڻ جي خاصيتن ڏانهن موٽڻ، اهو صحيح دستاويز ۾ لکيل آهي صارفين >= موضوع جا حصا. پر مون کي ان جي باري ۾ گهڻو پوء معلوم ٿيو ته مون کي پسند ڪيو ها. جيڪڏھن توھان چاھيو ٿا ماپ ۽ ٻه صارف آھن، توھان کي ضرورت آھي گھٽ ۾ گھٽ ٻن ڀاڱن جي. اهو آهي، جيڪڏهن توهان وٽ هڪ ورهاڱو هو جنهن ۾ 20 هزار پيغام جمع ٿي چڪا هئا، ۽ توهان هڪ نئون ٺاهيو، پيغامن جو تعداد جلدي برابر نه ٿيندو. تنهن ڪري، ٻه متوازي صارفين حاصل ڪرڻ لاء، توهان کي ورهاڱي سان معاملو ڪرڻو پوندو.
مانيٽرنگ
منهنجو خيال آهي ته جنهن طريقي سان اسان مانيٽر ڪنداسين اهو اڃا به واضح ٿي ويندو ته موجوده طريقي ۾ ڪهڙا مسئلا آهن.
مثال طور، اسان ڳڻپ ڪريون ٿا ته ڊيٽابيس ۾ ڪيتريون پراڊڪٽس تازو ئي پنهنجون حالتون تبديل ڪيون آهن، ۽، مطابق، واقعا انهن تبديلين جي بنياد تي ٿيڻ گهرجن، ۽ اسان اهو نمبر اسان جي نگراني واري نظام ڏانهن موڪليندا آهيون. پوءِ ڪافڪا کان اسان کي ٻيو نمبر ملي ٿو ته اصل ۾ ڪيترا واقعا رڪارڊ ڪيا ويا. ظاهر آهي، انهن ٻن انگن جي وچ ۾ فرق هميشه صفر هجڻ گهرجي.
اضافي طور تي، توهان کي مانيٽر ڪرڻ جي ضرورت آهي ته پيدا ڪندڙ ڪيئن ڪري رهيو آهي، ڇا واقعا-بس پيغام وصول ڪيا آهن، ۽ صارف ڪيئن ڪري رهيا آهن. مثال طور، ھيٺ ڏنل چارٽ ۾، واپسي وارو اوزار سٺو ڪم ڪري رھيو آھي، پر BOB واضح طور تي ڪجھ مسئلا آھن (نيري چوٽيون).
مون اڳ ۾ ئي ذڪر ڪيو آهي صارفين-گروپ جي وقفي. عام طور تي ڳالهائڻ، هي اڻ پڙهيل پيغامن جو تعداد آهي. عام طور تي، اسان جا صارف جلدي ڪم ڪن ٿا، تنهنڪري وقفو عام طور تي 0 آهي، پر ڪڏهن ڪڏهن اتي ٿي سگهي ٿو مختصر مدت جي چوٽي. ڪافڪا هن کي دٻي کان ٻاهر ڪري سگهي ٿو، پر توهان کي هڪ خاص وقفو مقرر ڪرڻو پوندو.
ھڪڙو منصوبو آھي جيڪو توهان کي ڪافڪا بابت وڌيڪ معلومات ڏيندو. اهو صرف استعمال ڪري ٿو صارفين-گروپ API جي حيثيت ڏيڻ لاءِ ته هي گروپ ڪيئن ڪري رهيو آهي. OK ۽ ناڪامي جي اضافي ۾، هڪ ڊيڄاريندڙ آهي، ۽ توهان ڳولي سگهو ٿا ته توهان جا صارف پيداوار جي رفتار سان مقابلو نٿا ڪري سگهن - انهن وٽ اهو وقت نه آهي ته ڇا لکيو ويو آهي. سسٽم تمام هوشيار ۽ استعمال ڪرڻ آسان آهي.
اھو اھو آھي جيڪو API جو جواب ڏسڻ ۾ اچي ٿو. هتي آهي گروپ باب-لائيو-فيفا، ورهاڱي جي واپسي.update.v1، اسٽيٽس ٺيڪ، lag 0 - آخري فائنل آفسيٽ اهڙي ۽ اهڙي.
مانيٽرنگ update_at SLA (پڪڙيل) مون اڳ ۾ ئي ذڪر ڪيو آهي. مثال طور، پيداوار جي حيثيت ۾ تبديل ٿي وئي آهي ته اها واپسي لاء تيار آهي. اسان انسٽال ڪريون ٿا ڪرن، جنهن جو چوڻ آهي ته جيڪڏهن 5 منٽن ۾ هي اعتراض واپس نه ويو آهي (اسان ادائگي جي سسٽم ذريعي پئسا واپس ڪريون ٿا تمام جلدي)، پوء ڪجهه ضرور غلط ٿي ويو، ۽ اهو ضرور مدد لاء هڪ ڪيس آهي. تنهن ڪري، اسان صرف ڪرون وٺو، جيڪو اهڙيون شيون پڙهي ٿو، ۽ جيڪڏهن اهي 0 کان وڌيڪ آهن، پوء اهو هڪ الرٽ موڪلي ٿو.
اختصار ڪرڻ لاء، واقعن کي استعمال ڪرڻ آسان آهي جڏهن:
- معلومات ڪيترن ئي سسٽم جي ضرورت آهي؛
- پروسيسنگ جو نتيجو اهم نه آهي؛
- ڪجھ واقعا يا ننڍا واقعا آھن.
اهو لڳي ٿو ته آرٽيڪل هڪ تمام خاص موضوع آهي - ڪافڪا تي غير مطابقت واري API، پر ان جي سلسلي ۾ آئون هڪ ڀيرو تمام گهڻيون شيون سفارش ڪرڻ چاهيندس.
پهريون، اڳيان اسان کي نومبر تائين انتظار ڪرڻو پوندو؛ اپريل ۾ سينٽ پيٽرس برگ جو نسخو هوندو، ۽ جون ۾ اسان نووسيبيرڪ ۾ وڌيڪ لوڊشيڊنگ بابت ڳالهائينداسين.
ٻيو، رپورٽ جو ليکڪ، سرگئي زائيڪا، علم جي انتظام تي اسان جي نئين ڪانفرنس جي پروگرام ڪميٽي جو ميمبر آهي. . ڪانفرنس هڪ ڏينهن جي آهي، 26 اپريل تي ٿيندي، پر ان جو پروگرام ڏاڍو تيز آهي.
۽ اهو مئي ۾ ٿيندو и (devOpsConf شامل ڪرڻ سان) - توھان پڻ اتي پنھنجو موضوع تجويز ڪري سگھو ٿا، پنھنجي تجربي جي باري ۾ ڳالھائي سگھو ٿا ۽ پنھنجي ڀريل شنک بابت شڪايت ڪري سگھو ٿا.
جو ذريعو: www.habr.com