هيلو سڀ! منهنجو نالو سرجي ڪوسٽانبايف آهي، ايڪسچينج تي مان واپار جي بنيادي نظام کي ترقي ڪري رهيو آهيان.
جڏهن هالي ووڊ جون فلمون نيو يارڪ اسٽاڪ ايڪسچينج ڏيکارينديون آهن، تڏهن هميشه هن طرح نظر ايندي آهي: ماڻهن جو هجوم، هر ڪو ڪجهه نه ڪجهه ڪري رهيو آهي، ڪاغذ لڙڪائي رهيا آهن، مڪمل افراتفري ٿي رهي آهي. اهو هتي ماسڪو ايڪسچينج تي ڪڏهن به نه ٿيو آهي، ڇاڪاڻ ته واپار شروع کان ئي اليڪٽرانڪ طور تي ڪيو ويو آهي ۽ ٻن مکيه پليٽ فارمن تي ٻڌل آهي - اسپيڪٽرا (فارڪس مارڪيٽ) ۽ ASTS (پرڏيهي مٽا سٽا، اسٽاڪ ۽ مني مارڪيٽ). ۽ اڄ آئون ASTS واپار ۽ صاف ڪرڻ واري نظام جي فن تعمير جي ارتقاء بابت، مختلف حلن ۽ نتيجن بابت ڳالهائڻ چاهيان ٿو. ڪهاڻي ڊگهي ٿيندي، ان ڪري مون کي ان کي ٻن حصن ۾ ورهائڻو پيو.
اسان دنيا جي انهن چند مٽاسٽا مان هڪ آهيون جيڪي سڀني طبقن جي اثاثن جو واپار ڪن ٿا ۽ مٽاسٽا جون خدمتون مهيا ڪن ٿيون. مثال طور، گذريل سال اسان بانڊ واپاري حجم جي لحاظ کان دنيا ۾ ٻئي نمبر تي، سڀني اسٽاڪ ايڪسچينجز جي وچ ۾ 25th جڳهه، عوامي ايڪسچينجز جي وچ ۾ سرمائيداري ۾ 13th جڳهه.
پيشه ورانه واپاري شرڪت ڪندڙن لاءِ، اهڙا پيرا ميٽرز جيئن ته جوابي وقت، وقت جي ورڇ جي استحڪام (جٽر) ۽ پوري ڪمپليڪس جي ڀروسي اهم آهن. اسان في الحال روزانو لکين ٽرانزيڪشن تي عمل ڪريون ٿا. سسٽم ڪرنل پاران هر ٽرانزيڪشن جي پروسيسنگ ۾ ڏهن مائڪرو سيڪنڊن جو وقت لڳندو آهي. يقينن، نئين سال جي شام تي موبائل آپريٽرز يا سرچ انجڻ پاڻ ۾ اسان جي ڀيٽ ۾ وڌيڪ ڪم لوڊ آهن، پر ڪم لوڊ جي لحاظ کان، مٿي ڄاڻايل خاصيتن سان گڏ، ڪجھه اسان سان مقابلو ڪري سگھن ٿا، اهو مون کي لڳي ٿو. ساڳئي وقت، اهو اسان لاء ضروري آهي ته سسٽم هڪ سيڪنڊ لاء سست نه ٿئي، بلڪل مستحڪم طور تي ڪم ڪري ٿو، ۽ سڀئي صارف هڪ جيتري سطح تي آهن.
ٿوري تاريخ
1994 ۾، آسٽريليا ASTS سسٽم ماسڪو انٽربئنڪ ڪرنسي ايڪسچينج (MICEX) تي شروع ڪيو ويو، ۽ ان وقت کان روسي تاريخ جي اليڪٽرانڪ واپار جي تاريخ شمار ڪري سگهجي ٿي. 1998 ۾، مٽا سٽا جي فن تعمير کي جديد ڪيو ويو انٽرنيٽ واپار کي متعارف ڪرائڻ لاء. ان وقت کان وٺي، سڀني سسٽم ۽ سب سسٽم ۾ نئين حل ۽ تعميراتي تبديلين تي عمل درآمد جي رفتار صرف رفتار حاصل ڪري رهي آهي.
انهن سالن ۾، ايڪسچينج سسٽم هاء-اينڊ هارڊويئر تي ڪم ڪيو - الٽرا-قابل اعتماد HP سپرڊوم 9000 سرورز (تعمير ٿيل.)، جنهن ۾ بلڪل سڀڪنھن شيء کي نقل ڪيو ويو: ان پٽ/آئوٽ پٽ سبسسٽم، نيٽ ورڪ، رام (حقيقت ۾، رام جي ھڪڙي RAID صف ھئي)، پروسيسرز (گرم-swappable). اهو ممڪن هو ته ڪنهن به سرور جو حصو تبديل ڪرڻ بغير مشين کي روڪيو. اسان انهن ڊوائيسز تي ڀروسو ڪيو ۽ انهن کي عملي طور تي ناڪام-محفوظ سمجهيو. آپريٽنگ سسٽم يونڪس جهڙو HP UX سسٽم هو.
پر اٽڪل 2010 کان وٺي، ھڪڙو رجحان اڀري آيو آھي جنھن کي سڏيو ويندو آھي ھاء فريڪوئنسي ٽريڊنگ (HFT)، يا ھاء فريڪوئنسي ٽريڊنگ - سادو رکو، اسٽاڪ ايڪسچينج روبوٽس. صرف 2,5 سالن ۾، اسان جي سرورن تي لوڊ 140 ڀيرا وڌي ويو آهي.
پراڻي فن تعمير ۽ سامان سان اهڙي لوڊ برداشت ڪرڻ ناممڪن هو. اهو ضروري هو ته ڪنهن به طريقي سان ترتيب ڏيو.
شروعات
تبادلي جي نظام جي درخواستن کي ٻن قسمن ۾ ورهائي سگھجي ٿو:
- معاملو. جيڪڏھن توھان چاھيو ٿا ڊالر، شيئرز يا ٻيو ڪجھ خريد ڪريو، توھان موڪليندا ھڪ ٽرانزيڪشن واپاري نظام ڏانھن ۽ وصول ڪريو ڪاميابيءَ بابت جواب.
- معلومات جي درخواست. جيڪڏھن توھان چاھيو ٿا موجوده قيمت معلوم ڪريو، ڏسو آرڊر بڪ يا انڊيڪس، پوءِ موڪليو معلومات جون درخواستون.
Schematically، نظام جي بنيادي ٽن سطحن ۾ تقسيم ڪري سگهجي ٿو:
- ڪلائنٽ جي سطح، جنهن تي بروکرز ۽ گراهڪ ڪم ڪن ٿا. اهي سڀئي رسائي سرور سان رابطو ڪن ٿا.
- گيٽ وي سرورز ڪيشنگ سرور آهن جيڪي مقامي طور تي سڀني معلومات جي درخواستن تي عمل ڪن ٿا. ڇا توھان ڄاڻڻ چاھيو ٿا ته Sberbank جا حصا ھن وقت ڪھڙي قيمت تي واپار ڪري رھيا آھن؟ درخواست رسائي سرور ڏانهن وڃي ٿي.
- پر جيڪڏهن توهان شيئر خريد ڪرڻ چاهيو ٿا، ته پوءِ درخواست مرڪزي سرور ڏانهن وڃي ٿي (تجارتي انجڻ). هر قسم جي مارڪيٽ لاءِ هڪ اهڙو سرور آهي، اهي هڪ اهم ڪردار ادا ڪن ٿا، اهو انهن لاءِ آهي ته اسان اهو نظام ٺاهيو آهي.
واپاري نظام جو بنيادي هڪ ذهين ياداشت واري ڊيٽابيس آهي جنهن ۾ سڀ ٽرانزيڪشن مٽا سٽا وارا ٽرانزيڪشن آهن. بنيادي طور تي C ۾ لکيل هو، صرف خارجي انحصار libc لائبريري هئي ۽ اتي ڪا به متحرڪ ياداشت مختص نه هئي. پروسيسنگ جي وقت کي گھٽائڻ لاء، سسٽم شروع ٿئي ٿو هڪ جامد سيٽ سان ۽ جامد ڊيٽا جي منتقلي سان: پهريون، موجوده ڏينهن جي سڀني ڊيٽا کي ميموري ۾ لوڊ ڪيو ويو آهي، ۽ وڌيڪ ڊسڪ تائين رسائي نه ڪئي وئي آهي، سڀ ڪم صرف ميموري ۾ ڪيو ويندو آهي. جڏهن سسٽم شروع ٿئي ٿو، سڀني حوالن واري ڊيٽا اڳ ۾ ئي ترتيب ڏنل آهي، تنهنڪري ڳولا تمام موثر طريقي سان ڪم ڪري ٿي ۽ رن ٽائم ۾ ٿورو وقت وٺندو آهي. سڀئي جدول متحرڪ ڊيٽا جي جوڙجڪ لاءِ مداخلت واري فهرستن ۽ وڻن سان ٺهيل آهن ته جيئن انهن کي رن ٽائم تي ميموري مختص ڪرڻ جي ضرورت نه پوي.
اچو ته مختصر طور تي اسان جي واپار ۽ صاف ڪرڻ واري نظام جي ترقي جي تاريخ تي وڃو.
واپار ۽ صاف ڪرڻ واري نظام جو پهريون نسخو نام نهاد يونڪس رابطي تي تعمير ڪيو ويو: گڏيل ياداشت، سيمفورس ۽ قطار استعمال ڪيا ويا، ۽ هر عمل هڪ واحد موضوع تي مشتمل آهي. اهو طريقو 1990 جي شروعات ۾ وسيع هو.
سسٽم جو پهريون نسخو گيٽ وي جي ٻن سطحن تي مشتمل آهي ۽ واپاري نظام جو هڪ مرڪزي سرور. ڪم جو سلسلو هن طرح هو:
- ڪلائنٽ هڪ درخواست موڪلي ٿو، جيڪا گيٽ وي تائين پهچي ٿي. اهو فارميٽ جي صحيحيت جي جانچ ڪري ٿو (پر ڊيٽا پاڻ نه) ۽ غلط ٽرانزيڪشن کي رد ڪري ٿو.
- جيڪڏهن هڪ معلومات جي درخواست موڪلي وئي آهي، اهو مقامي طور تي عمل ڪيو ويندو آهي؛ جيڪڏهن اسان هڪ ٽرانزيڪشن بابت ڳالهائي رهيا آهيون، پوء اهو مرڪزي سرور ڏانهن منتقل ڪيو ويو آهي.
- واپاري انجڻ وري ٽرانزيڪشن کي پروسيس ڪري ٿو، مقامي ياداشت کي تبديل ڪري ٿو، ۽ ٽرانزيڪشن جو جواب موڪلي ٿو ۽ ٽرانزيڪشن پاڻ کي الڳ نقل واري انجڻ استعمال ڪندي نقل لاءِ.
- گيٽ وي مرڪزي نوڊ کان جواب وصول ڪري ٿو ۽ ان کي ڪلائنٽ ڏانهن موڪلي ٿو.
- ڪجهه وقت کان پوء، گيٽ وي ٽرانزيڪشن کي نقل ڪرڻ واري ميڪانيزم ذريعي حاصل ڪري ٿو، ۽ هن ڀيري اهو مقامي طور تي عمل ڪري ٿو، ان جي ڊيٽا جي جوڙجڪ کي تبديل ڪري ٿو ته جيئن ايندڙ معلومات جي درخواستن کي تازي ڊيٽا ڏيکاري.
حقيقت ۾، اهو هڪ نقل ماڊل بيان ڪري ٿو جنهن ۾ گيٽ وي مڪمل طور تي واپار واري نظام ۾ ڪيل عملن کي نقل ڪيو. هڪ الڳ نقل ڪرڻ واري چينل کي يقيني بڻايو ويو ته ٽرانزيڪشن ساڳئي ترتيب ۾ ڪيترن ئي رسائي نوڊس تي عمل ڪيو ويو.
جيئن ته ڪوڊ سنگل ٿريڊ ٿيل هو، پروسيس فورڪ سان گڏ هڪ کلاسک اسڪيم ڪيترن ئي گراهڪن جي خدمت ڪرڻ لاءِ استعمال ڪيو ويو. بهرحال، پوري ڊيٽابيس کي ڪانٽو ڪرڻ تمام مهانگو هو، تنهنڪري هلڪو وزن سروس پروسيس استعمال ڪيو ويو جيڪي پيڪٽس گڏ ڪري TCP سيشن مان گڏ ڪيا ويا ۽ انهن کي هڪ قطار (SystemV Message Queue) ۾ منتقل ڪيو ويو. گيٽ وي ۽ ٽريڊ انجڻ صرف هن قطار سان ڪم ڪيو، اتان کان ٽرانزيڪشن وٺڻ لاءِ. اهو هاڻي ممڪن نه هو ته ان جو جواب موڪلڻ، ڇاڪاڻ ته اهو واضح نه هو ته ڪهڙي خدمت جي عمل کي پڙهڻ گهرجي. تنهن ڪري اسان هڪ چال جو رستو اختيار ڪيو: هر هڪ ڇڪيل عمل پنهنجي لاءِ هڪ جوابي قطار ٺاهي، ۽ جڏهن ڪا درخواست ايندڙ قطار ۾ آئي، ته جوابي قطار لاءِ هڪ ٽيگ فوري طور تي شامل ڪيو ويو.
مسلسل ڊيٽا جي وڏي مقدار کي نقل ڪندي قطار کان قطار ۾ پيدا ٿيل مسئلا، خاص طور تي عام معلومات جي درخواستن لاء. تنهن ڪري، اسان هڪ ٻي چال استعمال ڪئي: جوابي قطار جي اضافي ۾، هر عمل پڻ ٺاهيل شيئر ميموري (SystemV Shared Memory). پيڪيجز پاڻ ان ۾ رکيا ويا، ۽ صرف هڪ ٽيگ قطار ۾ محفوظ ڪيو ويو، هڪ کي اصل پيڪيج ڳولڻ جي اجازت ڏني وئي. هن پروسيسر ڪيش ۾ ڊيٽا کي ذخيرو ڪرڻ ۾ مدد ڪئي.
SystemV IPC ۾ قطار، ميموري، ۽ سيمفور شين جي حالت ڏسڻ لاءِ افاديت شامل آهن. اسان هن کي فعال طور تي استعمال ڪيو اهو سمجهڻ لاءِ ته سسٽم ۾ ڇا ٿي رهيو آهي ڪنهن خاص لمحي ۾، جتي پيڪيٽ جمع ٿيا، ڇا بند ڪيو ويو، وغيره.
پهرين جديديت
سڀ کان پهريان، اسان اڪيلو پروسيس گيٽ وي کان نجات حاصل ڪئي. ان جي اهم خرابي اها هئي ته اهو يا ته هڪ نقلي ٽرانزيڪشن يا ڪلائنٽ کان هڪ معلومات جي درخواست کي سنڀالي سگهي ٿو. ۽ جيئن لوڊ وڌندو، گيٽ وي درخواستن تي عمل ڪرڻ ۾ وڌيڪ وقت وٺندو ۽ نقل جي وهڪري کي پروسيس ڪرڻ جي قابل نه هوندو. اضافي طور تي، جيڪڏهن ڪلائنٽ هڪ ٽرانزيڪشن موڪليو، ته توهان کي صرف ان جي صحيحيت کي جانچڻ ۽ ان کي اڳتي وڌائڻ جي ضرورت آهي. تنهن ڪري، اسان سنگل گيٽ وي پروسيس کي ڪيترن ئي حصن سان تبديل ڪيو جيڪي متوازي طور تي هلائي سگهن ٿا: گھڻن موضوعن واري معلومات ۽ ٽرانزيڪشن پروسيس هڪ ٻئي کان آزاد طور تي هڪ گڏيل ياداشت واري علائقي تي RW لاڪنگ استعمال ڪندي. ۽ ساڳئي وقت اسان متعارف ڪرايو ترسيل ۽ نقل جي عمل.
اعلي تعدد واپار جو اثر
فن تعمير جو مٿيون نسخو 2010 ع تائين موجود هو. ان دوران، اسان وڌيڪ مطمئن نه هئاسين HP سپرڊوم سرورز جي ڪارڪردگي کان. ان کان علاوه، PA-RISC فن تعمير عملي طور تي مري ويو؛ وينڊر ڪا به اهم تازه ڪاري پيش نه ڪئي. نتيجي طور، اسان HP UX/PA RISC کان Linux/x86 ڏانهن منتقل ٿيڻ شروع ڪيو. منتقلي جي رسائي سرور جي موافقت سان شروع ٿي.
اسان کي ٻيهر فن تعمير کي ڇو تبديل ڪرڻو پيو؟ حقيقت اها آهي ته اعلي تعدد واپار کي سسٽم ڪور تي لوڊ پروفائل کي خاص طور تي تبديل ڪيو آهي.
اچو ته چون ٿا ته اسان وٽ ھڪڙو ننڍڙو ٽرانزيڪشن آھي جنھن جي قيمت ۾ ھڪڙي وڏي تبديلي آئي آھي - ڪو ھڪڙو اڌ ارب ڊالر خريد ڪيو. ڪجھ مليس سيڪنڊن کان پوء، سڀني مارڪيٽ شرڪت ڪندڙ ھن کي نوٽيس ڪندا آھن ۽ ھڪڙي اصلاح ڪرڻ شروع ڪندا آھن. قدرتي طور تي، درخواستون هڪ وڏي قطار ۾ قطار ۾ آهن، جنهن کي صاف ڪرڻ لاء سسٽم گهڻو وقت وٺندو.
ھن 50 ms جي وقفي تي، سراسري رفتار اٽڪل 16 ھزار ٽرانزيڪشن في سيڪنڊ آھي. جيڪڏهن اسان ونڊو کي 20 ms تائين گھٽائينداسين، اسان کي 90 هزار ٽرانزيڪشن في سيڪنڊ جي سراسري رفتار حاصل ٿيندي، 200 هزار ٽرانزيڪشن جي چوٽي تي. ٻين لفظن ۾، لوڊ مسلسل نه آهي، اوچتو دفن سان. ۽ درخواستن جي قطار کي هميشه تيزي سان عمل ڪيو وڃي.
پر اتي ئي قطار ڇو آهي؟ تنهن ڪري، اسان جي مثال ۾، ڪيترن ئي صارفين قيمت جي تبديلي کي محسوس ڪيو ۽ ان مطابق ٽرانزيڪشن موڪليو. اهي گيٽ وي تي اچن ٿا، اهو انهن کي ترتيب ڏئي ٿو، هڪ خاص آرڊر مقرر ڪري ٿو ۽ انهن کي نيٽ ورڪ ڏانهن موڪلي ٿو. روٽر پيٽرن کي ڦيرايو ۽ انهن کي اڳتي وڌايو. جنهن جو پيڪيج پهريون ڀيرو آيو، اهو ٽرانزيڪشن ”جيت“. نتيجي طور، ايڪسچينج ڪلائنٽ نوٽيس ڪرڻ شروع ڪيو ته جيڪڏهن ساڳيو ٽرانزيڪشن ڪيترن ئي گيٽ ويز کان موڪليو ويو، ته پوء ان جي تيز رفتار پروسيسنگ جا موقعا وڌي ويا. جلد ئي، ايڪسچينج روبوٽ گيٽ وي تي بمباري ڪرڻ شروع ڪيو درخواستن سان، ۽ ٽرانزيڪشن جو هڪ برفاني طوفان پيدا ٿيو.
ارتقاء جو هڪ نئون دور
وسيع جاچ ۽ تحقيق کان پوء، اسان کي تبديل ڪيو حقيقي وقت آپريٽنگ سسٽم ڪرنل. ان لاءِ اسان چونڊيو RedHat Enterprise MRG Linux، جتي MRG جو مطلب آھي ميسيجنگ ريئل ٽائيم گرڊ. حقيقي وقت جي پيچ جو فائدو اهو آهي ته اهي سسٽم کي تيز ترين ممڪن عمل لاء بهتر بڻائين ٿا: سڀئي عمل هڪ FIFO قطار ۾ قطار ڪيا ويا آهن، ڪور کي الڳ ڪري سگهجي ٿو، نڪرندڙ نه، سڀ ٽرانزيڪشن سخت ترتيب ۾ پروسيس ڪيا ويندا آهن.
ڳاڙهو - هڪ قطار سان باقاعده ڪنييل ۾ ڪم ڪرڻ، سائو - حقيقي وقت جي ڪني ۾ ڪم ڪرڻ.
پر باقاعده سرورز تي گهٽ ويڪرائي حاصل ڪرڻ ايترو آسان ناهي:
- ايس ايم آئي موڊ، جيڪو x86 فن تعمير ۾ اهم پرديئرز سان ڪم ڪرڻ جو بنياد آهي، تمام گهڻو مداخلت ڪري ٿو. سڀني قسمن جي هارڊويئر واقعن جي پروسيسنگ ۽ اجزاء ۽ ڊوائيسز جو انتظام فرم ویئر پاران نام نهاد شفاف SMI موڊ ۾ ڪيو ويندو آهي، جنهن ۾ آپريٽنگ سسٽم اهو نه ڏسي ٿو ته فرم ویئر ڇا ڪري رهيو آهي. ضابطي جي طور تي، سڀني وڏن وينڊرز فرم ويئر سرورز لاء خاص توسيع پيش ڪن ٿيون جيڪي SMI پروسيسنگ جي مقدار کي گھٽائڻ جي اجازت ڏين ٿيون.
- پروسيسر جي تعدد جو ڪوبه متحرڪ ڪنٽرول نه هجڻ گهرجي، اهو اضافي دير جي وقت تائين پهچندو آهي.
- جڏهن فائل سسٽم لاگ فلش ڪيو ويندو آهي، ڪجهه عمل ڪني ۾ واقع ٿينديون آهن جيڪي غير متوقع دير جو سبب بڻجن ٿيون.
- توهان کي ڌيان ڏيڻ جي ضرورت آهي شين جهڙوڪ CPU لاڳاپو، مداخلت لاڳاپو، NUMA.
مون کي ضرور چوڻ گهرجي ته ريئل ٽائيم پروسيسنگ لاءِ لينڪس هارڊويئر ۽ ڪنيل قائم ڪرڻ جو موضوع هڪ الڳ مضمون جو مستحق آهي. اسان سٺو نتيجو حاصل ڪرڻ کان اڳ اسان تجربو ۽ تحقيق ڪرڻ ۾ گهڻو وقت گذاريو.
جڏهن PA-RISC سرورز کان x86 ڏانهن منتقل ڪيو ويو، اسان کي عملي طور تي سسٽم ڪوڊ تبديل ڪرڻ جي ضرورت نه هئي، اسان صرف ان کي ترتيب ڏنو ۽ ٻيهر ترتيب ڏنو. ساڳئي وقت، اسان ڪيترن ئي مسئلن کي درست ڪيو. مثال طور، ان حقيقت جا نتيجا ته PA RISC هڪ وڏو اينڊين سسٽم هو، ۽ x86 هڪ ننڍڙو اينڊين سسٽم هو، جلدي طور تي ظاهر ٿيو: مثال طور، ڊيٽا غلط پڙهي وئي هئي. مشڪل بگ اهو هو ته PA RISC استعمال ڪري ٿو () ياداشت جي رسائي، جڏهن ته x86 پڙهڻ جي عملن کي ٻيهر ترتيب ڏئي سگهي ٿو، تنهنڪري ڪوڊ جيڪو هڪ پليٽ فارم تي بلڪل صحيح هو ٻئي تي ڀڄي ويو.
x86 تي سوئچ ڪرڻ کان پوء، ڪارڪردگي تقريبا ٽي ڀيرا وڌي وئي، اوسط ٽرانزيڪشن پروسيسنگ وقت 60 μs تائين گھٽجي ويو.
اچو ته هاڻي هڪ ويجهي نظر رکون ٿا ته ڪهڙيون اهم تبديليون سسٽم جي فن تعمير ۾ ڪيون ويون آهن.
گرم رزرو ايپيڪ
جڏهن ڪموڊٽي سرورز ڏانهن مٽائي رهيا هئاسين، اسان کي خبر هئي ته اهي گهٽ قابل اعتماد هئا. تنهن ڪري، جڏهن هڪ نئين فن تعمير ٺاهيندي، اسان کي ترجيح ڏني وئي آهي ته هڪ يا وڌيڪ نوڊس جي ناڪامي جو امڪان. تنهن ڪري، هڪ گرم اسٽينڊ بائي سسٽم جي ضرورت هئي جيڪا تمام جلدي بيڪ اپ مشين ڏانهن سوئچ ڪري سگهي ٿي.
ان کان سواء، ٻيون ضرورتون هيون:
- ڪنهن به حالت ۾ توهان کي پروسيس ٿيل ٽرانزيڪشن کي وڃائڻ نه گهرجي.
- سسٽم اسان جي انفراسٽرڪچر کي بلڪل شفاف هجڻ گهرجي.
- گراهڪ کي نه ڏسڻ گهرجي ڪنيڪشن ختم ٿيل.
- رزرويشن کي اهم تاخير متعارف نه ٿيڻ گهرجي ڇو ته هي بدلي لاءِ هڪ اهم عنصر آهي.
جڏهن هڪ گرم اسٽينڊ بائي سسٽم ٺاهيندي، اسان اهڙين حالتن تي غور نه ڪيو جيئن ڊبل ناڪامي (مثال طور، هڪ سرور تي نيٽ ورڪ ڪم ڪرڻ بند ڪيو ۽ مکيه سرور منجمد)؛ سافٽ ويئر ۾ غلطين جي امڪان تي غور نه ڪيو ڇاڪاڻ ته اهي جاچ دوران سڃاڻپ ڪيا ويا آهن؛ ۽ هارڊويئر جي غلط آپريشن تي غور نه ڪيو.
نتيجي طور، اسان ھيٺ ڏنل اسڪيم ڏانھن آيا:
- مکيه سرور سڌو سنئون گيٽ وي سرور سان رابطو ڪيو.
- مکيه سرور تي حاصل ڪيل سڀني ٽرانزيڪشن کي فوري طور تي هڪ الڳ چينل ذريعي بيڪ اپ سرور ڏانهن نقل ڪيو ويو. ثالث (گورنر) جيڪڏهن ڪو مسئلو پيدا ٿئي ته سوئچنگ کي هموار ڪيو.
- مکيه سرور هر ٽرانزيڪشن تي عمل ڪيو ۽ بيڪ اپ سرور کان تصديق جي انتظار ۾. گھٽ ۾ گھٽ ويڪرائي رکڻ لاءِ، اسان بيڪ اپ سرور تي ٽرانزيڪشن مڪمل ٿيڻ جي انتظار کان پاسو ڪيو. ان وقت کان وٺي جيڪو ٽرانزيڪشن لاءِ سڄي نيٽ ورڪ ۾ سفر ڪرڻ لاءِ ورتو ويو ان جي مقابلي واري وقت سان، ڪا به اضافي دير نه ڪئي وئي.
- اسان صرف پوئين ٽرانزيڪشن لاءِ مکيه ۽ بيڪ اپ سرورز جي پروسيسنگ اسٽيٽس کي چيڪ ڪري سگهون ٿا، ۽ موجوده ٽرانزيڪشن جي پروسيسنگ اسٽيٽس نامعلوم هئي. جيئن ته اسان اڃا تائين واحد ڌاڳو وارا عمل استعمال ڪري رهيا هئاسين، بيڪ اپ مان جواب جي انتظار ۾ پوري پروسيسنگ جي وهڪري کي سست ڪري ڇڏي ها، تنهنڪري اسان هڪ مناسب سمجھوتو ڪيو: اسان اڳئين ٽرانزيڪشن جو نتيجو چيڪ ڪيو.
هن منصوبي هيٺ ڪم ڪيو.
اچو ته چوندا آهن مکيه سرور جواب ڏيڻ بند ڪري ٿو، پر گيٽ ويز گفتگو جاري رکندا آهن. بيڪ اپ سرور تي هڪ وقت ختم ٿئي ٿو، اهو گورنر سان رابطو ڪري ٿو، جيڪو ان کي مکيه سرور جو ڪردار تفويض ڪري ٿو، ۽ سڀئي گيٽ ويز نئين مکيه سرور ڏانهن سوئچ ڪن ٿا.
جيڪڏهن مکيه سرور واپس آن لائن اچي ٿو، اهو پڻ هڪ اندروني وقت ختم ڪري ٿو، ڇاڪاڻ ته اتي هڪ خاص وقت لاء گيٽ وي کان سرور تي ڪو به ڪال نه آهي. پوءِ هو به گورنر ڏانهن رخ ڪري ٿو، ۽ هو کيس اسڪيم مان خارج ڪري ٿو. نتيجي طور، مٽا سٽا هڪ سرور سان واپار جي مدت جي آخر تائين ڪم ڪندو آهي. جيئن ته سرور جي ناڪامي جو امڪان تمام گهٽ آهي، هن اسڪيم کي ڪافي قابل قبول سمجهيو ويندو هو؛ ان ۾ پيچيده منطق شامل نه هئي ۽ ٽيسٽ ڪرڻ آسان هو.
جاري رکڻ لاء
جو ذريعو: www.habr.com