اسان جا صارف هڪ ٻئي ڏانهن پيغام لکندا آهن بغير ڪنهن ٿڪاوٽ جي.
اهو تمام گهڻو آهي. جيڪڏهن توهان سڀني صارفين جي سڀني پيغامن کي پڙهڻ لاء تيار ڪيو، اهو 150 هزار سالن کان وڌيڪ وٺندو. بشرطيڪ توهان هڪ انتهائي ترقي يافته پڙهندڙ آهيو ۽ هر پيغام تي هڪ سيڪنڊ کان وڌيڪ خرچ نه ڪريو.
ڊيٽا جي اهڙي مقدار سان، اهو ضروري آهي ته ان کي محفوظ ڪرڻ ۽ ان جي رسائي لاء منطق بهتر طور تي ٺهيل آهي. ٻي صورت ۾، هڪ نه عجيب لمحي ۾، اهو واضح ٿي سگهي ٿو ته هر شيء جلد ئي غلط ٿي ويندي.
اسان لاء، اهو لمحو هڪ اڌ سال اڳ آيو هو. اسان هن کي ڪيئن آيا ۽ آخر ۾ ڇا ٿيو - اسان توهان کي ترتيب ۾ ٻڌايو.
پس منظر
پهرين ئي عمل ۾، VKontakte پيغامن PHP پس منظر ۽ MySQL جي ميلاپ تي ڪم ڪيو. اهو هڪ ننڍڙو شاگرد ويب سائيٽ لاء مڪمل طور تي عام حل آهي. بهرحال، هي سائيٽ بي قابو ٿي وڌي ۽ پنهنجي لاءِ ڊيٽا جي جوڙجڪ جي اصلاح جو مطالبو ڪرڻ شروع ڪيو.
2009 جي آخر ۾، پهريون ٽيڪسٽ انجڻ مخزن لکيو ويو، ۽ 2010 ۾ پيغام ان کي منتقل ڪيو ويو.
ٽيڪسٽ انجڻ ۾، پيغامن کي فهرستن ۾ محفوظ ڪيو ويو - هڪ قسم جو "ميل باڪس". هر اهڙي فهرست هڪ uid پاران طئي ڪئي وئي آهي - صارف جيڪو انهن سڀني پيغامن جو مالڪ آهي. هڪ پيغام ۾ خاصيتن جو هڪ سيٽ هوندو آهي: ڳالهائيندڙ سڃاڻپ ڪندڙ، متن، منسلڪات، وغيره. "باڪس" اندر پيغام جي سڃاڻپ ڪندڙ آهي local_id، اهو ڪڏهن به تبديل نٿو ڪري ۽ نئين پيغامن لاء ترتيب سان لڳايو ويو آهي. "باڪس" آزاد آهن ۽ انجڻ جي اندر هڪ ٻئي سان هم وقت سازي نه آهن؛ انهن جي وچ ۾ رابطي PHP سطح تي ٿئي ٿي. توھان اندر مان ڊيٽا جي جوڙجڪ ۽ ٽيڪسٽ انجڻ جي صلاحيتن کي ڏسي سگھو ٿا .
اهو ڪافي هو ٻن استعمال ڪندڙن جي وچ ۾ خط و ڪتابت لاءِ. اندازو لڳايو ته اڳتي ڇا ٿيو؟
مئي 2011 ۾، VKontakte ڪيترن ئي شرڪت ڪندڙن سان ڳالھ ٻولھ متعارف ڪرايو - گھڻن چيٽ. انھن سان گڏ ڪم ڪرڻ لاءِ، اسان ٻه نوان ڪلسٽر اٿاريا - ميمبر-چيٽ ۽ چيٽ-ميمبر. پهريون ذخيرو صارفين جي چيٽ بابت ڊيٽا، ٻيو ذخيرو صارفين جي باري ۾ ڊيٽا چيٽ ذريعي. پاڻ لسٽن کان علاوه، ھن ۾ شامل آھي، مثال طور، مدعو ڪندڙ صارف ۽ وقت انھن کي چيٽ ۾ شامل ڪيو ويو.
"PHP، اچو ته چيٽ ڏانهن پيغام موڪليو،" صارف چوي ٿو.
"اچو، {username}،" PHP چوي ٿو.
هن اسڪيم جا نقصان آهن. هم وقت سازي اڃا تائين PHP جي ذميواري آهي. وڏيون چيٽ ۽ استعمال ڪندڙ جيڪي هڪ ئي وقت انهن ڏانهن پيغام موڪليندا آهن هڪ خطرناڪ ڪهاڻي آهي. جيئن ته ٽيڪسٽ انجڻ جو مثال uid تي منحصر آهي، چيٽ شرڪت ڪندڙن کي مختلف وقتن تي ساڳيو پيغام ملي سگهي ٿو. هڪ ماڻهو ان سان گڏ رهي سگهي ٿو جيڪڏهن ترقي اڃا بيٺي رهي. پر ائين نه ٿيندو.
2015 جي آخر ۾، اسان ڪميونٽي پيغام شروع ڪيو، ۽ 2016 جي شروعات ۾، اسان انھن لاءِ API شروع ڪيو. برادرين ۾ وڏي چيٽ بوٽس جي آمد سان، اهو ممڪن هو ته لوڊ ورهائڻ جي باري ۾ وسارڻ.
هڪ سٺو بوٽ هر ڏينهن ڪيترن ئي ملين پيغامن کي پيدا ڪري ٿو - جيتوڻيڪ سڀ کان وڌيڪ ڳالهائيندڙ استعمال ڪندڙ ان تي فخر نٿا ڪري سگهن. هن جو مطلب آهي ته ٽيڪسٽ انجڻ جا ڪجهه مثال، جن تي اهڙا بوٽ رهندا هئا، مڪمل طور تي متاثر ٿيڻ شروع ڪيو.
2016 ۾ ميسيج انجڻ 100 مثالون چيٽ-ميمبرن ۽ ميمبر-چيٽس، ۽ 8000 ٽيڪسٽ-انجن. اهي هڪ هزار سرورز تي ميزباني ڪيا ويا، هر هڪ 64 GB ياداشت سان. پهرين هنگامي ماپ جي طور تي، اسان ميموري کي ٻي 32 GB تائين وڌايو. اسان اڳڪٿين جو اندازو لڳايو. بغير سخت تبديلين جي، اهو ڪافي ٿيندو هڪ ٻئي سال لاء. توهان کي يا ته هارڊويئر کي هٿي وٺڻ جي ضرورت آهي يا پاڻ ڊيٽابيس کي بهتر ڪرڻ جي ضرورت آهي.
فن تعمير جي نوعيت جي ڪري، اهو صرف سمجهه ۾ اچي ٿو ته هارڊويئر کي ضرب ۾ وڌايو وڃي. اهو آهي، گهٽ ۾ گهٽ ڪارن جي تعداد کي ٻيڻو ڪرڻ - ظاهر آهي، اهو هڪ قيمتي رستو آهي. اسان اصلاح ڪنداسين.
نئون تصور
نئين انداز جو مرڪزي جوهر چيٽ آهي. هڪ چيٽ پيغامن جي هڪ فهرست آهي جيڪا ان سان لاڳاپيل آهي. استعمال ڪندڙ کي چيٽ جي هڪ فهرست آهي.
گھربل گھٽ ۾ گھٽ ٻه نوان ڊيٽابيس آھن:
- چيٽ انجڻ. هي چيٽ ویکٹرز جو هڪ مخزن آهي. هر چيٽ ۾ پيغامن جو هڪ ویکٹر هوندو آهي جيڪو ان سان لاڳاپيل هوندو آهي. هر پيغام ۾ هڪ متن آهي ۽ چيٽ جي اندر هڪ منفرد پيغام جي سڃاڻپ ڪندڙ آهي - chat_local_id.
- استعمال ڪندڙ انجڻ. هي صارفين ویکٹرز جو هڪ ذخيرو آهي - صارفين لاء لنڪس. هر صارف وٽ peer_id جو هڪ ویکٹر هوندو آهي (ڳالهائيندڙ - ٻيا استعمال ڪندڙ، ملٽي چيٽ يا ڪميونٽي) ۽ پيغامن جو هڪ ویکٹر. هر peer_id ۾ پيغامن جو هڪ ویکٹر هوندو آهي جيڪو ان سان لاڳاپيل هوندو آهي. هر پيغام ۾ هڪ chat_local_id آهي ۽ ان صارف لاءِ هڪ منفرد پيغام ID آهي - user_local_id.
نون ڪلستر TCP استعمال ڪندي هڪ ٻئي سان رابطو ڪن ٿا - اهو يقيني بڻائي ٿو ته درخواستن جي ترتيب تبديل نه ٿيندي. پاڻ درخواستون ۽ انهن لاءِ تصديقون هارڊ ڊرائيو تي رڪارڊ ٿيل آهن - تنهنڪري اسان انجڻ جي ناڪامي يا ٻيهر شروع ٿيڻ کان پوءِ ڪنهن به وقت قطار جي حالت بحال ڪري سگهون ٿا. جيئن ته يوزر انجڻ ۽ چيٽ انجڻ هر هڪ 4 هزار شارڊس آهن، ان ڪري ڪلستر جي وچ ۾ درخواست جي قطار برابر ورهائجي ويندي (پر حقيقت ۾ ڪو به ناهي - ۽ اهو تمام جلدي ڪم ڪري ٿو).
اسان جي ڊيٽابيس ۾ ڊسڪ سان ڪم ڪرڻ اڪثر ڪيسن ۾ بائنري لاگ تبديلين (بن لاگ)، جامد سنيپ شاٽ ۽ ياداشت ۾ هڪ جزوي تصوير جي ميلاپ تي ٻڌل آهي. ڏينهن جي دوران تبديليون هڪ binlog ڏانهن لکيل آهن، ۽ موجوده حالت جو هڪ سنيپ شاٽ وقتي طور تي ٺاهيو ويندو آهي. هڪ سنيپ شاٽ ڊيٽا جي جوڙجڪ جو هڪ مجموعو آهي جيڪو اسان جي مقصدن لاءِ بهتر ڪيو ويو آهي. اهو هڪ هيڊر تي مشتمل آهي (تصوير جو ميٽائنڪس) ۽ ميٽا فائلن جو هڪ سيٽ. هيڊر مستقل طور تي RAM ۾ ذخيرو ٿيل آهي ۽ اشارو ڪري ٿو ته ڪٿي سنيپ شاٽ مان ڊيٽا ڳولڻ لاء. هر ميٽ فائل ۾ ڊيٽا شامل آهي جيڪا وقت جي ويجهو پوائنٽن تي گهربل هجي - مثال طور، هڪ واحد صارف سان لاڳاپيل. جڏهن توهان سنيپ شاٽ هيڊر استعمال ڪندي ڊيٽابيس کان سوال ڪندا آهيو، گهربل ميٽ فائل پڙهي ويندي آهي، ۽ پوءِ سنيپ شاٽ ٺهڻ کان پوءِ بين لاگ ۾ ٿيندڙ تبديلين کي نظر ۾ رکيو ويندو آهي. توهان هن طريقي جي فائدن بابت وڌيڪ پڙهي سگهو ٿا .
ساڳئي وقت، هارڊ ڊرائيو تي ڊيٽا پاڻ کي صرف هڪ ڀيرو تبديل ڪري ٿو - ماسڪو ۾ رات جو دير سان، جڏهن لوڊ گهٽ ۾ گهٽ آهي. انهي جي مهرباني (ڄاڻڻ ته ڊسڪ تي ڍانچي سڄو ڏينهن مسلسل آهي)، اسان هڪ مقرر ڪيل سائيز جي صفن سان ویکٹر کي تبديل ڪرڻ جي متحمل ڪري سگهون ٿا - ۽ انهي جي ڪري، ياداشت ۾ حاصل ٿئي ٿي.
نئين اسڪيم ۾ پيغام موڪلڻ هن طرح نظر اچي ٿو:
- PHP پس منظر هڪ پيغام موڪلڻ جي درخواست سان صارف انجڻ سان رابطو ڪري ٿو.
- يوزر-انجڻ گهربل چيٽ-انجڻ جي مثال جي درخواست کي پراڪس ڪري ٿو، جيڪو يوزر-انجڻ chat_local_id ڏانهن موٽندو آهي - هن چيٽ ۾ هڪ نئين پيغام جو هڪ منفرد سڃاڻپ ڪندڙ. chat_engine وري چيٽ ۾ سڀني وصول ڪندڙن کي پيغام نشر ڪري ٿو.
- يوزر-انجڻ چيٽ-انجڻ مان chat_local_id وصول ڪري ٿو ۽ user_local_id کي PHP ڏانهن موٽائي ٿو - هن صارف لاءِ هڪ منفرد پيغام جي سڃاڻپ ڪندڙ. هي سڃاڻپ ڪندڙ پوءِ استعمال ڪيو ويندو آهي، مثال طور، API ذريعي پيغامن سان ڪم ڪرڻ لاءِ.
پر اصل ۾ پيغام موڪلڻ کان علاوه، توهان کي ڪجهه وڌيڪ اهم شيون لاڳو ڪرڻ جي ضرورت آهي:
- ذيلي فهرستون آھن، مثال طور، سڀ کان تازا پيغام جيڪي توھان ڏسندا آھيو جڏھن گفتگو جي فهرست کولڻ وقت. اڻ پڙهيل پيغام، ٽيگ سان پيغام ("اهم"، "اسپام"، وغيره).
- چيٽ انجڻ ۾ پيغامن کي دٻائڻ
- يوزر انجڻ ۾ پيغامن کي ڪيش ڪرڻ
- ڳولھيو (سڀني ڊائلاگ ذريعي ۽ ھڪڙي مخصوص ۾).
- حقيقي وقت اپڊيٽ (لانگ پولنگ).
- موبائيل ڪلائنٽ تي ڪيشنگ کي لاڳو ڪرڻ لاءِ تاريخ محفوظ ڪرڻ.
سڀئي ذيلي فهرستون تيزيء سان تبديل ٿيندڙ جوڙجڪ آھن. ان سان گڏ ڪم ڪرڻ لاء اسان استعمال ڪندا آهيون . هن پسند جي وضاحت هن حقيقت سان ڪئي وئي آهي ته وڻ جي چوٽيءَ تي اسين ڪڏهن ڪڏهن هڪ سنيپ شاٽ مان پيغامن جو هڪ سڄو حصو ذخيرو ڪندا آهيون - مثال طور، رات جي ريڊيڪسنگ کان پوءِ، وڻ هڪ ٽاپ تي مشتمل هوندو آهي، جنهن ۾ سب لسٽ جا سڀئي پيغام شامل هوندا آهن. اسپلي وڻ کي توازن جي باري ۾ سوچڻ کان سواء اهڙي عمودي جي وچ ۾ داخل ڪرڻ آسان بڻائي ٿي. ان کان سواء، اسپلي غير ضروري ڊيٽا کي ذخيرو نٿو ڪري، جيڪو اسان جي ياداشت کي بچائيندو آهي.
پيغامن ۾ معلومات جو هڪ وڏو مقدار شامل آهي، گهڻو ڪري ٽيڪسٽ، جيڪو ڪمپريس ڪرڻ جي قابل هوندو آهي. اهو ضروري آهي ته اسان هڪ انفرادي پيغام کي صحيح طور تي غير محفوظ ڪري سگهون ٿا. پيغامن کي دٻائڻ لاءِ استعمال ڪيو ويو مثال طور، اسان ڄاڻون ٿا ته پيغامن ۾ لفظ ”غير لفظن“ سان متبادل ٿين ٿا- اسپيس، اوقاف جا نشان- ۽ اسان کي روسي ٻوليءَ لاءِ علامتون استعمال ڪرڻ جون ڪي خاصيتون به ياد آهن.
جيئن ته چيٽ جي ڀيٽ ۾ تمام گهٽ استعمال ڪندڙ آهن، بي ترتيب واري رسائي واري ڊسڪ جي درخواستن کي چيٽ انجڻ ۾ محفوظ ڪرڻ لاءِ، اسان پيغامن کي صارف انجڻ ۾ ڪيش ڪندا آهيون.
پيغام جي ڳولا کي استعمال ڪندڙ-انجڻ کان وٺي سڀني چيٽ-انجڻ جي مثالن تائين هڪ ڊرون سوال طور لاڳو ڪيو ويو آهي جنهن ۾ هن صارف جي چيٽ شامل آهن. نتيجا پاڻ ۾ استعمال ڪندڙ-انجڻ ۾ گڏيل آهن.
خير، سڀني تفصيلن کي حساب ۾ ورتو ويو آهي، باقي رهي ٿو هڪ نئين اسڪيم ڏانهن سوئچ ڪرڻ - ۽ ترجيحي طور تي صارفين ان کي نوٽيس ڪرڻ کان سواء.
ڊيٽا جي منتقلي
تنهن ڪري، اسان وٽ هڪ ٽيڪسٽ انجڻ آهي جيڪو ذخيرو ڪري ٿو صارف طرفان پيغام، ۽ ٻه ڪلسٽر چيٽ-ميمبرز ۽ ميمبر-چيٽس جيڪي ملٽي چيٽ رومز ۽ انهن ۾ استعمال ڪندڙن بابت ڊيٽا محفوظ ڪن ٿا. ان مان نئين يوزر انجڻ ۽ چيٽ انجڻ تائين ڪيئن منتقل ڪجي؟
پراڻي اسڪيم ۾ ميمبر-چيٽس بنيادي طور تي اصلاح لاءِ استعمال ڪيا ويا. اسان جلدي ان مان ضروري ڊيٽا چيٽ-ميمبرن ڏانهن منتقل ڪيو، ۽ پوءِ ان لڏپلاڻ جي عمل ۾ حصو نه ورتو.
چيٽ-ميمبرن لاءِ قطار. ان ۾ 100 مثال شامل آهن، جڏهن ته چيٽ انجڻ 4 هزار آهن. ڊيٽا کي منتقلي ڪرڻ لاء، توهان کي ان جي تعميل ۾ آڻڻ جي ضرورت آهي - ان لاء، چيٽ ميمبرن کي ساڳيا 4 هزار ڪاپي ۾ ورهايو ويو، ۽ پوء چيٽ-ميمبرز بن لاگ پڙهڻ کي چيٽ انجڻ ۾ فعال ڪيو ويو.
ھاڻي چيٽ-انجڻ چيٽ-ميمبرن کان ملٽي چيٽ بابت ڄاڻي ٿو، پر اھو اڃا تائين ٻن ڳالھائيندڙن سان گفتگو بابت ڪجھ به نه ٿو ڄاڻي. اهڙا ڊائلاگ استعمال ڪندڙن جي حوالي سان ٽيڪسٽ انجڻ ۾ موجود آهن. هتي اسان ڊيٽا کي ”هيڊ آن“ ورتو: هر چيٽ-انجڻ جي مثال سڀني ٽيڪسٽ-انجڻ جي مثالن کان پڇيو ته ڇا انهن وٽ اها ڳالهه ٻولهه گهربل هئي.
عظيم - چيٽ-انجڻ ڄاڻي ٿو ته اتي ڪهڙيون ملٽي چيٽ چيٽ آهن ۽ ڄاڻي ٿي ته اتي ڪهڙا ڊائلاگ آهن.
توهان کي ملٽي چيٽ چيٽ ۾ پيغامن کي گڏ ڪرڻ جي ضرورت آهي ته جيئن توهان هر چيٽ ۾ پيغامن جي هڪ فهرست سان ختم ڪريو. پهريون، چيٽ-انجڻ ٽيڪسٽ انجڻ مان حاصل ڪري ٿو سڀني صارفن جي پيغامن کي هن چيٽ مان. ڪجهه حالتن ۾ انهن مان تمام گهڻا آهن (سوين لکن تائين)، پر تمام ناياب استثنا سان، چيٽ مڪمل طور تي رام ۾ اچي ٿو. اسان وٽ اڻ ترتيب ڏنل پيغام آهن، هر هڪ ڪيترن ئي نقلن ۾ - آخرڪار، اهي سڀئي مختلف ٽيڪسٽ انجڻ جي مثالن مان ڪڍيا ويا آهن جيڪي صارفين سان لاڳاپيل آهن. مقصد پيغامن کي ترتيب ڏيڻ ۽ نقلن کان نجات حاصل ڪرڻ آهي جيڪي غير ضروري جاء وٺن ٿيون.
هر پيغام ۾ هڪ ٽائم اسٽيمپ آهي جنهن ۾ اهو وقت ۽ ٽيڪسٽ موڪليو ويو آهي. اسان ترتيب ڏيڻ لاءِ وقت استعمال ڪندا آهيون - اسان ملٽي چيٽ شرڪت ڪندڙن جي پراڻين پيغامن ڏانهن اشارو رکون ٿا ۽ هيشز جو مقابلو ڪريون ٿا ارادي ڪاپي جي متن مان، ٽائم اسٽيمپ کي وڌائڻ طرف. اهو منطقي آهي ته ڪاپيون ساڳيون هيش ۽ ٽائم اسٽيمپ هونديون، پر عملي طور تي اهو هميشه ناهي. جئين توهان کي ياد آهي، پراڻي اسڪيم ۾ هم وقت سازي PHP پاران ڪئي وئي هئي - ۽ نادر ڪيسن ۾، ساڳئي پيغام موڪلڻ جو وقت مختلف صارفين جي وچ ۾ مختلف آهي. انهن حالتن ۾، اسان پاڻ کي ٽائيم اسٽيمپ کي تبديل ڪرڻ جي اجازت ڏني - عام طور تي هڪ سيڪنڊ جي اندر. ٻيو مسئلو مختلف وصول ڪندڙن لاءِ پيغامن جو مختلف ترتيب آهي. اهڙين حالتن ۾، اسان هڪ اضافي ڪاپي پيدا ڪرڻ جي اجازت ڏني، مختلف صارفين لاء مختلف ترتيب ڏيڻ جي اختيارن سان.
ان کان پوء، ملٽي چيٽ ۾ پيغامن بابت ڊيٽا صارف-انجن ڏانهن موڪليو ويو آهي. ۽ هتي درآمد ٿيل پيغامن جي هڪ ناپسنديده خصوصيت اچي ٿي. عام آپريشن ۾، پيغام جيڪي انجڻ تي اچن ٿا، سختي سان ترتيب ڏنل ترتيب ۾ صارف_local_id پاران ترتيب ڏنل آهن. پراڻي انجڻ مان درآمد ٿيل نياپا استعمال ڪندڙ انجڻ ۾ ھن مفيد ملڪيت کي وڃائي ڇڏيو. ساڳئي وقت، جانچ جي سهولت لاء، توهان کي انهن کي جلدي رسائي حاصل ڪرڻ جي ضرورت آهي، انهن ۾ ڪجهه ڳوليو ۽ نوان شامل ڪريو.
اسان درآمد ٿيل پيغامن کي ذخيرو ڪرڻ لاءِ خاص ڊيٽا جي جوڙجڪ استعمال ڪندا آهيون.
اهو ماپ جي ویکٹر جي نمائندگي ڪري ٿو هرڪو ڪٿي آهي - مختلف آهن ۽ ترتيب ڏنل ترتيب ۾، عناصر جي هڪ خاص ترتيب سان. هر حصي ۾ اشارن سان عناصر ترتيب ڏنل آهن. اهڙي جوڙجڪ ۾ هڪ عنصر جي ڳولا وقت وٺندو آهي через بائنري ڳولها. هڪ عنصر جي اضافي تي amortized آهي .
تنهن ڪري، اسان اهو معلوم ڪيو ته ڪيئن پراڻي انجڻين مان ڊيٽا کي نئين ڏانهن منتقل ڪرڻ. پر اهو عمل ڪيترائي ڏينهن وٺندو آهي - ۽ اهو ممڪن ناهي ته انهن ڏينهن دوران اسان جا استعمال ڪندڙ هڪ ٻئي ڏانهن لکڻ جي عادت ڇڏيندا. هن وقت دوران پيغامن کي نه وڃائڻ لاءِ، اسان هڪ ڪم واري اسڪيم ڏانهن وڃون ٿا جيڪو ٻنهي پراڻن ۽ نئين ڪلسترن کي استعمال ڪري ٿو.
ڊيٽا چيٽ-ميمبرن ۽ استعمال ڪندڙ-انجن ڏانهن لکيو ويو آهي (۽ متن-انجڻ ڏانهن نه، جيئن پراڻي اسڪيم مطابق عام آپريشن ۾). يوزر-انجڻ چيٽ-انجڻ جي درخواست کي پراڪس ڪري ٿو - ۽ هتي اهو عمل ان ڳالهه تي منحصر آهي ته ڇا هي چيٽ اڳ ۾ ئي ضم ٿي چڪو آهي يا نه. جيڪڏهن چيٽ اڃا تائين ضم نه ڪئي وئي آهي، چيٽ انجڻ پاڻ ڏانهن پيغام نه لکندو آهي، ۽ ان جي پروسيسنگ صرف ٽيڪسٽ انجڻ ۾ ٿيندي آهي. جيڪڏهن چيٽ کي اڳ ۾ ئي چيٽ-انجڻ ۾ ضم ڪيو ويو آهي، اهو chat_local_id کي يوزر-انجڻ ڏانهن موٽائي ٿو ۽ سڀني وصول ڪندڙن کي پيغام موڪلي ٿو. يوزر انجڻ سموري ڊيٽا کي ٽيڪسٽ انجڻ تي پراڪس ڪري ٿو - انهي ڪري ته جيڪڏهن ڪجهه ٿئي ٿو، اسان هميشه کي واپس ڪري سگهون ٿا، پراڻي انجڻ ۾ موجود سموري ڊيٽا کي. ٽيڪسٽ-انجڻ user_local_id کي واپس ڏئي ٿو، جيڪو صارف-انجڻ اسٽور ڪري ٿو ۽ واپسي ڏانهن موٽائي ٿو.
نتيجي طور، منتقلي جو عمل هن طرح نظر اچي ٿو: اسان خالي صارف-انجڻ ۽ چيٽ-انجڻ جي ڪلستر کي ڳنڍيندا آهيون. چيٽ-انجڻ سڄي چيٽ-ميمبرز بنلاگ کي پڙهي ٿو، پوءِ مٿي بيان ڪيل اسڪيم مطابق پراڪسنگ شروع ٿئي ٿي. اسان پراڻي ڊيٽا کي منتقل ڪريون ٿا ۽ ٻه هم وقت سازي ڪلستر (پراڻي ۽ نئون) حاصل ڪريو. باقي اهو آهي ته پڙهڻ کي ٽيڪسٽ-انجڻ کان صارف-انجن ڏانهن تبديل ڪرڻ ۽ پراکسينگ کي بند ڪرڻ.
نتيجا
نئين طريقي جي مهرباني، انجڻ جي سڀني ڪارڪردگي جي ماپ کي بهتر ڪيو ويو آهي ۽ ڊيٽا جي استحڪام سان مسئلا حل ڪيا ويا آهن. ھاڻي اسان فوري طور تي پيغامن ۾ نيون خصوصيتون لاڳو ڪري سگھون ٿا (۽ اڳ ۾ ئي اھو ڪرڻ شروع ڪري ڇڏيو آھي - اسان چيٽ شرڪت ڪندڙن جو وڌ ۾ وڌ تعداد وڌايو، فارورڊ ڪيل پيغامن جي ڳولا تي عمل ڪيو، پن ٿيل پيغامن کي شروع ڪيو ۽ في صارف پيغامن جي ڪل تعداد تي حد وڌائي) .
منطق ۾ تبديليون واقعي وڏيون آهن. ۽ مان اهو نوٽ ڪرڻ چاهيان ٿو ته اهو هميشه هڪ وڏي ٽيم ۽ ڪوڊ جي لائنن جي ڪيترن ئي سالن جي ترقي جو مطلب ناهي. chat-انجڻ ۽ يوزر-انجڻ سان گڏ سڀني اضافي ڪهاڻيون جهڙوڪ هفمن لاءِ ميسيج ڪمپريشن، اسپلي ٽريز ۽ امپورٽ ٿيل پيغامن لاءِ ڍانچي 20 هزار لائنن کان گهٽ ڪوڊ آهي. ۽ اهي 3 ڊولپرز طرفان لکيا ويا صرف 10 مهينن ۾ (جڏهن ته، اهو ذهن ۾ رکڻ جي قابل آهي ته - ورلڊ چيمپئنز ).
ان کان علاوه، سرور جي تعداد کي ٻيڻو ڪرڻ جي بدران، اسان انهن جو تعداد اڌ کان گھٽ ڪيو - هاڻي صارف-انجن ۽ چيٽ-انجڻ 500 فزيڪل مشينن تي رهن ٿا، جڏهن ته نئين اسڪيم ۾ لوڊ ڪرڻ لاء هڪ وڏو هيڊ روم آهي. اسان سامان تي تمام گھڻو پئسا بچايو - اٽڪل $5 ملين + $750 هزار في سال آپريٽنگ خرچن ۾.
اسان سڀ کان وڌيڪ پيچيده ۽ وڏي پيماني تي مسئلن لاء بهترين حل ڳولڻ جي ڪوشش ڪندا آهيون. اسان وٽ انھن مان گھڻا آھن - ۽ اھو ئي سبب آھي جو اسين ڳولي رھيا آھيون باصلاحيت ڊولپرز کي ڊيٽابيس ڊپارٽمينٽ ۾. جيڪڏھن توھان پيار ڪندا آھيو ۽ ڄاڻو ٿا ته اھڙين مسئلن کي ڪيئن حل ڪجي، توھان کي الورورٿمز ۽ ڊيٽا جي جوڙجڪ جي بھترين ڄاڻ آھي، اسان توھان کي ٽيم ۾ شامل ٿيڻ جي دعوت ڏيون ٿا. اسان سان رابطو ڪريو تفصيل لاءِ.
جيتوڻيڪ اها ڪهاڻي توهان جي باري ۾ نه آهي، مهرباني ڪري نوٽ ڪريو ته اسان سفارشن کي اهميت ڏين ٿا. ڪنهن دوست کي ٻڌايو ، ۽ جيڪڏھن اھو ڪاميابيءَ سان امتحان واري مدت پوري ڪري، توھان کي 100 ھزار روبل جو بونس ملندو.
جو ذريعو: www.habr.com