Artem Denisov ( , )
Badoo دنيا جي سڀ کان وڏي تاريخ جي سائيٽ آهي. اسان وٽ هن وقت سڄي دنيا ۾ 330 ملين رجسٽرڊ استعمال ڪندڙ آهن. پر اڄ اسان جي گفتگو جي حوالي سان جيڪا شيءِ وڌيڪ اهم آهي، سا اها آهي ته اسان اٽڪل 3 پيٽابائيٽس استعمال ڪندڙ جي تصويرن کي ذخيرو ڪندا آهيون. هر روز اسان جا صارف اٽڪل 3,5 ملين نيون تصويرون اپلوڊ ڪندا آهن، ۽ پڙهڻ وارو لوڊ تقريباً آهي 80 هزار درخواستون في سيڪنڊ. اهو اسان جي پسمنظر لاء ڪافي آهي، ۽ ڪڏهن ڪڏهن هن سان مشڪلاتون آهن.
مان هن سسٽم جي ڊزائن بابت ڳالهائيندس، جيڪو عام طور تي فوٽوز کي اسٽور ۽ موڪلي ٿو، ۽ مان ان کي ڊولپر جي نقطي نظر کان ڏسندس. هتي هڪ مختصر پس منظر هوندو ته اهو ڪيئن ترقي ڪري ٿو، جتي آئون مکيه سنگ ميلن کي بيان ڪندس، پر مان صرف انهن حلن بابت وڌيڪ تفصيل سان ڳالهائيندس جيڪي اسان هن وقت استعمال ڪري رهيا آهيون.
هاڻي اچو ته شروع ڪريون.
جيئن مون چيو، اهو هڪ ريٽروسپيڪٽو هوندو، ۽ ان کي ڪٿي شروع ڪرڻ لاءِ، اچو ته سڀ کان عام مثال وٺون.
اسان وٽ ھڪڙو عام ڪم آھي، اسان کي قبول ڪرڻ، ذخيرو ڪرڻ ۽ صارف فوٽو موڪلڻ جي ضرورت آھي. هن فارم ۾، ڪم عام آهي، اسان ڪجھ به استعمال ڪري سگهون ٿا:
- جديد بادل اسٽوريج،
- هڪ باڪس ٿيل حل، جنهن مان هاڻي تمام گهڻو آهن؛
- اسان پنھنجي ڊيٽا سينٽر ۾ ڪيتريون ئي مشينون سيٽ ڪري سگھون ٿا ۽ انھن تي وڏيون هارڊ ڊرائيوون رکي سگھون ٿا ۽ اتي فوٽو اسٽور ڪري سگھون ٿا.
بدو تاريخي طور تي - هاڻي ۽ پوءِ (جڏهن اهو صرف پنهنجي ننڍپڻ ۾ هو) - اسان جي پنهنجي ڊي سي جي اندر، پنهنجي سرور تي رهندو آهي. تنهن ڪري، هي اختيار اسان لاء بهترين هو.
اسان صرف ڪيتريون ئي مشينون ورتيون، انهن کي سڏيو "فوٽو"، ۽ اسان کي هڪ ڪلستر مليو جيڪو فوٽوز کي ذخيرو ڪري ٿو. پر اهو لڳي ٿو ته ڪجهه غائب آهي. اهو سڀ ڪم ڪرڻ لاءِ، اسان کي ڪنهن نه ڪنهن طريقي سان اهو طئي ڪرڻو پوندو ته ڪهڙي مشين تي اسين ڪهڙيون تصويرون محفوظ ڪنداسين. ۽ هتي، پڻ، آمريڪا کي کولڻ جي ڪا ضرورت ناهي.
اسان استعمال ڪندڙن بابت معلومات سان گڏ اسان جي اسٽوريج ۾ ڪجهه فيلڊ شامل ڪندا آهيون. هي هوندو شارڊنگ ڪيڏو. اسان جي حالت ۾، اسان ان کي سڏيو آهي place_id، ۽ هي جڳهه id ان هنڌ ڏانهن اشارو ڪري ٿو جتي صارف جون تصويرون ذخيرو ٿيل آهن. اسان نقشا ٺاهيندا آهيون.
پهرين مرحلي ۾، اهو پڻ دستي طور تي ڪري سگهجي ٿو - اسان چئون ٿا ته هن صارف جي تصوير اهڙي جڳهه سان اهڙي سرور تي اچي ويندي. هن نقشي جي مهرباني، اسان هميشه ڄاڻون ٿا ته صارف هڪ فوٽو اپ لوڊ ڪري ٿو، ان کي ڪٿي محفوظ ڪرڻ، ۽ اسان ڄاڻون ٿا ته ان کي ڪٿان ڏيو.
هي هڪ تمام معمولي اسڪيم آهي، پر ان ۾ ڪافي اهم فائدا آهن. پهريون اهو آهي ته اهو سادو آهي، جيئن مون چيو آهي، ۽ ٻيو اهو آهي ته هن طريقي سان اسان آساني سان افقي طور تي ماپ ڪري سگهون ٿا صرف نيون ڪارون پهچائڻ ۽ انهن کي نقشي ۾ شامل ڪندي. توهان کي ٻيو ڪجهه ڪرڻ جي ضرورت ناهي.
ڪجهه وقت اسان لاءِ ائين ئي رهيو.
اهو 2009 جي ڀرسان هو. انهن ڪارن کي پهچايو، پهچايو ...
۽ ڪجهه نقطي تي اسان کي نوٽيس ڪرڻ شروع ڪيو ته هن منصوبي کي ڪجهه نقصان آهي. ڪهڙا نقصان آهن؟
سڀ کان اول، اتي محدود گنجائش آهي. اسان هڪ جسماني سرور تي جيتريون هارڊ ڊرائيوون نه ٿا ڪري سگهون جيئن اسان چاهيون ٿا. ۽ اهو وقت سان گڏ هڪ خاص مسئلو بڻجي چڪو آهي ۽ ڊيٽا سيٽ جي واڌ سان.
۽ ٻيو. هي مشينن جي هڪ غير معمولي ترتيب آهي، ڇاڪاڻ ته اهڙين مشينن کي ڪجهه ٻين ڪلستر ۾ ٻيهر استعمال ڪرڻ ڏکيو آهي؛ اهي ڪافي مخصوص آهن، يعني. انهن کي ڪارڪردگي ۾ ڪمزور هجڻ گهرجي، پر ساڳئي وقت هڪ وڏي هارڊ ڊرائيو سان.
اهو سڀ ڪجهه 2009 لاء هو، پر، اصول ۾، اهي گهرجون اڄ به لاڳاپيل آهن. اسان وٽ هڪ پسمانده آهي، تنهنڪري 2009 ۾ هر شيء مڪمل طور تي خراب هئي.
۽ آخري نقطو قيمت آهي.
قيمت ان وقت تمام تيز هئي، ۽ اسان کي ڪجهه متبادل ڳولڻ جي ضرورت هئي. اهي. اسان کي ڪنهن به طرح ڊيٽا سينٽرن ۽ فزيڪل سرورز ۾ موجود جڳهه ٻنهي کي بهتر استعمال ڪرڻ جي ضرورت آهي جنهن تي اهو سڀ واقع آهي. ۽ اسان جي سسٽم انجنيئرن هڪ وڏو مطالعو شروع ڪيو جنهن ۾ انهن مختلف اختيارن جو هڪ گروپ جائزو ورتو. اهي پڻ ڪلستر ٿيل فائل سسٽم تي نظر اچن ٿا جهڙوڪ پولي سيف ۽ Luster. اتي ڪارڪردگي مسئلا ۽ ڪافي ڏکيو آپريشن هئا. هنن انڪار ڪيو. اسان NFS ذريعي پوري ڊيٽا سيٽ کي هر ڪار تي نصب ڪرڻ جي ڪوشش ڪئي ته جيئن ڪنهن به طرح ان کي وڌايو وڃي. پڙهڻ پڻ خراب ٿي ويو، اسان مختلف وينڊرز کان مختلف حل جي ڪوشش ڪئي.
۽ آخر ۾، اسان نام نهاد اسٽوريج ايريا نيٽورڪ استعمال ڪرڻ تي آباد ٿيا.
اهي وڏا SHD آهن جيڪي خاص طور تي ٺهيل آهن ڊيٽا جي وڏي مقدار کي محفوظ ڪرڻ لاءِ. اهي شيلف آهن ڊسڪ سان جيڪي فائنل آپٽيڪل آئوٽ پٽ مشينن تي لڳل آهن. اهو. اسان وٽ ڪجھ قسم جي مشينن جو تلاءُ آھي، ڪافي ننڍيون، ۽ اھي SHDs، جيڪي اسان جي موڪلڻ واري منطق لاءِ شفاف آھن، يعني. اسان جي نينگڪس يا ڪنهن ٻئي لاءِ انهن تصويرن جي درخواستن جي خدمت ڪرڻ لاءِ.
هن فيصلي جا واضح فائدا هئا. هي SHD آهي. ان جو مقصد فوٽوز کي محفوظ ڪرڻ آهي. اهو ڪم سستو آهي صرف مشينن کي هارڊ ڊرائيو سان ليس ڪرڻ کان.
ٻيو پلس.
اهو آهي ته گنجائش تمام وڏي ٿي چڪي آهي، يعني. اسان هڪ تمام ننڍي مقدار ۾ گهڻو وڌيڪ اسٽوريج کي ترتيب ڏئي سگهون ٿا.
پر اتي پڻ نقصان هئا جيڪي تمام جلدي ظاهر ٿيا. جيئن ته صارفين جو تعداد ۽ هن سسٽم تي لوڊ وڌو، ڪارڪردگي مسئلا پيدا ٿيڻ شروع ڪيو. ۽ هتي مسئلو بلڪل واضح آهي - ڪنهن به SHD هڪ ننڍڙي مقدار ۾ ڪيترن ئي فوٽوز کي ذخيرو ڪرڻ لاء ٺهيل آهي، ضابطي جي طور تي، سخت پڙهڻ کان متاثر ٿئي ٿو. اهو اصل ۾ ڪنهن به ڪلائوڊ اسٽوريج يا ٻي ڪنهن شيءِ لاءِ صحيح آهي. ھاڻي اسان وٽ ھڪڙو مثالي اسٽوريج نه آھي جيڪو لامحدود طور تي اسپيبلبل ھوندو، توھان ان ۾ ڪجھ به سامان ڪري سگھوٿا، ۽ اھو پڙھڻ کي تمام سٺو برداشت ڪري سگھندو. خاص طور تي معمولي پڙهڻ.
جيئن اسان جي تصويرن جو معاملو آهي، ڇاڪاڻ ته فوٽوز غير مطابقت سان درخواست ڪئي وئي آهي، ۽ اهو انهن جي ڪارڪردگي کي تمام گهڻو متاثر ڪندو.
جيتوڻيڪ اڄ جي انگن اکرن موجب، جيڪڏهن اسان ڪنهن مشين تي فوٽوز لاء 500 RPS کان وڌيڪ حاصل ڪندا آهيون جنهن سان اسٽوريج ڳنڍيل آهي، مسئلا اڳ ۾ ئي شروع ٿي ويندا آهن. ۽ اهو اسان لاء ڪافي خراب هو، ڇاڪاڻ ته صارفين جو تعداد وڌي رهيو آهي، شيون صرف خراب ٿيڻ وارا آهن. انهي کي ڪنهن به طريقي سان بهتر ڪرڻ جي ضرورت آهي.
بهتر ڪرڻ لاء، اسان ان وقت فيصلو ڪيو، واضح طور تي، لوڊ پروفائل کي ڏسڻ لاء - ڇا، عام طور تي، ٿي رهيو آهي، ڇا کي بهتر ڪرڻ جي ضرورت آهي.
۽ هتي هر شيء اسان جي هٿن ۾ ادا ڪري ٿي.
مون اڳ ۾ ئي پهرين سلائيڊ ۾ چيو آهي: اسان وٽ في سيڪنڊ 80 هزار پڙهڻ جون درخواستون آهن صرف 3,5 ملين اپلوڊ في ڏينهن سان. اهو آهي، هي هڪ فرق آهي ٽن حڪمن جي شدت. اهو ظاهر آهي ته پڙهڻ کي بهتر ڪرڻ جي ضرورت آهي ۽ اهو عملي طور تي واضح آهي ته ڪيئن.
ھڪڙو وڌيڪ ننڍڙو نقطو آھي. خدمت جون خاصيتون اهڙيون آهن ته هڪ شخص رجسٽر ڪري ٿو، فوٽو اپ لوڊ ڪري ٿو، پوء فعال طور تي ٻين ماڻهن کي ڏسڻ شروع ڪري ٿو، انهن وانگر، ۽ فعال طور تي ٻين ماڻهن کي ڏيکاريو ويو آهي. پوءِ هو هڪ ساٿي ڳولي ٿو يا ڪو ساٿي نٿو ڳولي، اهو منحصر آهي ته اهو ڪيئن نڪتو، ۽ ٿوري دير لاءِ خدمت استعمال ڪرڻ بند ڪري ٿو. هن وقت، جڏهن هو ان کي استعمال ڪري ٿو، هن جون تصويرون تمام گرم آهن - اهي طلب ۾ آهن، گهڻا ماڻهو انهن کي ڏسندا آهن. جيترو جلدي هو اهو ڪرڻ بند ڪري ٿو، تمام جلدي هو ٻين ماڻهن جي تمام گهڻي نمائش کان ٻاهر نڪري ٿو، جيترو هن کان اڳ هو، ۽ هن جون تصويرون تقريبا ڪڏهن به درخواست نه ڪئي وئي آهي.
اهي. اسان وٽ ھڪڙو ننڍڙو گرم ڊيٽا سيٽ آھي. پر ساڳئي وقت هن لاء درخواستون تمام گهڻيون آهن. ۽ هتي هڪ مڪمل طور تي واضح حل آهي هڪ ڪيش شامل ڪرڻ.
LRU سان گڏ هڪ ڪيش اسان جا سڀ مسئلا حل ڪندو. اسان ڇا ڪري رهيا آهيون؟
اسان اسٽوريج سان گڏ اسان جي وڏي ڪلستر جي سامهون هڪ ٻيو نسبتا ننڍڙو شامل ڪيو، جنهن کي فوٽوڪچ سڏيو ويندو آهي. اهو بنيادي طور تي صرف هڪ ڪيشنگ پراکسي آهي.
اهو اندر کان ڪيئن ڪم ڪندو آهي؟ هتي اسان جو صارف آهي، هتي اسٽوريج آهي. سڀ ڪجهه اڳ جهڙو ئي آهي. اسان وچ ۾ ڇا شامل ڪريون؟
اهو صرف هڪ مشين آهي هڪ جسماني لوڪل ڊسڪ سان، جيڪو تيز آهي. اهو هڪ SSD سان آهي، مثال طور. ۽ ڪجهه قسم جي مقامي ڪيش هن ڊسڪ تي ذخيرو ٿيل آهي.
اهو ڇا وانگر آهي؟ صارف هڪ تصوير لاء درخواست موڪلي ٿو. NGINX ان کي ڳولي ٿو پهريون ڀيرو مقامي ڪيش ۾. جيڪڏهن نه، ته پوءِ بس اسان جي اسٽوريج ڏانهن proxy_pass، اتان فوٽو ڊائون لوڊ ڪريو ۽ صارف کي ڏيو.
پر هي هڪ تمام بيوقوف آهي ۽ اهو واضح ناهي ته اندر ڇا ٿي رهيو آهي. اهو ڪجهه هن طرح ڪم ڪري ٿو.
ڪيش منطقي طور تي ٽن تہن ۾ ورهايل آهي. جڏهن مان چوان ٿو "ٽي پرت"، ان جو مطلب اهو ناهي ته اتي ڪي پيچيده سسٽم آهي. نه، اهي شرطي طور تي فائل سسٽم ۾ صرف ٽي ڊائريڪٽريون آهن:
- هي هڪ بفر آهي جتي تصويرون صرف هڪ پراکسي وڃڻ کان ڊائون لوڊ ڪيون ويون آهن.
- هي هڪ گرم ڪيش آهي جيڪو اسٽور ڪري ٿو في الحال فعال طور تي درخواست ڪيل تصويرون.
- ۽ هڪ ٿڌو ڪيش، جتي تصويرون تيزيء سان گرم ڪيش مان ڪڍيا ويندا آهن جڏهن انهن وٽ گهٽ درخواستون اچن ٿيون.
ان لاءِ ڪم ڪرڻ لاءِ، اسان کي ڪنهن به طرح هن ڪيش کي منظم ڪرڻ جي ضرورت آهي، اسان کي ان ۾ فوٽوز کي ٻيهر ترتيب ڏيڻ جي ضرورت آهي، وغيره. اهو پڻ هڪ تمام ابتدائي عمل آهي.
نينگڪس هر درخواست لاءِ RAMDisk access.log ڏانهن صرف لکي ٿو، جنهن ۾ اهو اشارو ڪري ٿو ته تصوير ڏانهن رستو جيڪو هن وقت خدمت ڪيو آهي (لاڳاپو رستو، يقينا)، ۽ ڪهڙي ورهاڱي جي خدمت ڪئي وئي هئي. اهي. اهو چئي سگھي ٿو "فوٽو 1" ۽ پوءِ يا ته هڪ بفر، يا گرم ڪيش، يا ٿڌو ڪيش، يا هڪ پراڪسي.
هن تي مدار رکندي، اسان کي ڪنهن به طرح فيصلو ڪرڻو پوندو ته فوٽو سان ڇا ڪجي.
اسان وٽ هر مشين تي هڪ ننڍڙو ڊيمون هلندڙ آهي جيڪو مسلسل هن لاگ کي پڙهي ٿو ۽ پنهنجي ياداشت ۾ ڪجهه تصويرن جي استعمال تي شماريات محفوظ ڪري ٿو.
هو صرف اتي گڏ ڪري ٿو، ڳڻپيوڪر رکندو آهي ۽ وقتي طور تي هيٺيان ڪندو آهي. هو فعال طور تي درخواست ڪيل فوٽوز کي منتقل ڪري ٿو، جن لاء ڪيتريون ئي درخواستون آهن، گرم ڪيش ڏانهن، جتي اهي آهن.
تصويرون جيڪي گهٽ ۾ گهٽ درخواست ڪيون وينديون آهن ۽ گهٽ درخواستون ڪيون وينديون آهن انهن کي تيزيء سان گرم ڪيش مان ٻاهر ٿڌي ۾ ڌڪايو ويندو آهي.
۽ جڏهن اسان ڪيش ۾ جاءِ ختم ٿي وڃون ٿا، ته اسان صرف سرد ڪيش مان هر شيءِ کي اڻ سڌي طرح حذف ڪرڻ شروع ڪريون ٿا. ۽ رستي ۾، اهو سٺو ڪم ڪري ٿو.
تصوير کي فوري طور تي محفوظ ڪرڻ لاءِ جڏهن ان کي بفر ڏانهن پراکسي ڪيو وڃي، اسان استعمال ڪريون ٿا proxy_store هدايت ۽ بفر پڻ هڪ RAMDisk آهي، يعني. استعمال ڪندڙ لاء اهو تمام جلدي ڪم ڪري ٿو. اهو پاڻ کي ڪيشنگ سرور جي اندروني مسئلن جو تعلق آهي.
باقي سوال اهو آهي ته انهن سرورن ۾ درخواستن کي ڪيئن ورهايو وڃي.
اچو ته چوندا آهن ته ويهن اسٽوريج مشينن جو هڪ ڪلستر ۽ ٽي ڪيچنگ سرور (اهو ڪيئن ٿيو).
اسان کي ڪنهن به طرح اهو طئي ڪرڻو پوندو ته ڪهڙيون درخواستون ڪهڙيون تصويرون آهن ۽ انهن کي ڪٿي لينڊ ڪرڻو آهي.
سڀ کان وڌيڪ عام اختيار گول رابن آهي. يا حادثي سان ڪيو؟
انهي ۾ واضح طور تي ڪيترائي نقصان آهن ڇو ته اسان اهڙي صورتحال ۾ ڪيش کي تمام غير موثر طريقي سان استعمال ڪنداسين. درخواستون ڪجهه بي ترتيب مشينن تي لينڊ ٿينديون: هتي اهو ڪيش ڪيو ويو، پر ايندڙ هڪ تي اهو هاڻي ناهي. ۽ جيڪڏهن اهو سڀ ڪم ڪري ٿو، اهو تمام خراب ٿيندو. جيتوڻيڪ ڪلستر ۾ مشينن جي هڪ ننڍڙي تعداد سان.
اسان کي ڪنهن نه ڪنهن طريقي سان اهو طئي ڪرڻو پوندو ته ڪهڙي سرور کي لينڊ ڪرڻو آهي.
اتي هڪ سادي طريقو آهي. اسان URL مان هيش وٺون ٿا يا اسان جي شارڊنگ ڪيئي مان هيش، جيڪو URL ۾ آهي، ۽ ان کي سرور جي تعداد سان ورهايو. ڪم ڪندو؟ به.
اهي. اسان وٽ 2% درخواست آهي، مثال طور، ڪجهه “example_url” لاءِ اهو هميشه سرور تي انڊيڪس “XNUMX” سان لينڊ ڪندو، ۽ ڪيش کي مستقل طور تي ختم ڪيو ويندو جيترو ممڪن ٿي سگهي.
پر اهڙي اسڪيم ۾ ٻيهر شارڊنگ جو مسئلو آهي. ٻيهر شارڊنگ - منهنجو مطلب آهي سرورن جو تعداد تبديل ڪرڻ.
اچو ته فرض ڪريون ته اسان جو ڪيشنگ ڪلسٽر وڌيڪ نه ٿو ڪري سگهي ۽ اسان فيصلو ڪريون ٿا ٻي مشين شامل ڪرڻ جو.
اچو ته شامل ڪريو.
هاڻي هر شيءِ ٽن سان نه، پر چئن سان ورهائجي ٿي. اهڙيءَ طرح، لڳ ڀڳ سڀئي چاٻيون جيڪي اسان وٽ هيون، لڳ ڀڳ سڀئي URL هاڻي ٻين سرورن تي رهن ٿا. سڄو ڪيش صرف هڪ لمحي لاءِ باطل ٿي ويو. سڀئي درخواستون اسان جي اسٽوريج ڪلستر تي ٿي ويون، اهو خراب ٿي ويو، خدمت جي ناڪامي ۽ غير مطمئن صارفين. مان اهو نٿو ڪرڻ چاهيان.
هي اختيار اسان کي مناسب ناهي.
اهو. اسان کي ڇا ڪرڻ گهرجي؟ اسان کي ڪنهن نه ڪنهن طريقي سان ڪيش جو موثر استعمال ڪرڻ گهرجي، ساڳئي درخواست کي ساڳئي سرور تي بار بار لينڊ ڪرڻ گهرجي، پر ٻيهر شارڊنگ جي مزاحمتي ٿي. ۽ اتي ھڪڙو حل آھي، اھو اھو پيچيده نه آھي. ان کي مسلسل هيشنگ سڏيو ويندو آهي.
ڇا اهو نظر اچي ٿو؟
اسان شارڊنگ ڪيئي مان ڪجھ فنڪشن وٺون ٿا ۽ ان جي سڀني قدرن کي دائري تي پکڙيل آھيون. اهي. پوائنٽ 0 تي، ان جي گھٽ ۾ گھٽ ۽ وڌ ۾ وڌ قدر ملن ٿا. اڳيون، اسان اسان جي سڀني سرورن کي ساڳئي دائري تي تقريبا هن طريقي سان رکون ٿا:
هر سرور هڪ نقطي طرفان بيان ڪيو ويو آهي، ۽ اهو شعبو جيڪو گھڙي جي طرف وڃي ٿو، ان جي مطابق، هن ميزبان طرفان خدمت ڪئي وئي آهي. جڏهن اسان وٽ درخواستون اچن ٿيون، اسان فوري طور تي ڏسون ٿا، مثال طور، درخواست A - ان ۾ هڪ هيش آهي - ۽ اهو سرور 2 جي طرفان پيش ڪيو ويو آهي. درخواست B - سرور 3 طرفان. وغيره.
هن صورتحال ۾ ٻيهر شيڊنگ دوران ڇا ٿيندو؟
اسان پوري ڪيش کي باطل نه ٿا ڪريون، جيئن اڳ ۾، ۽ نه ئي سڀني ڪنيز کي شفٽ ڪندا آهيون، پر اسان هر شعبي کي ٿورڙي فاصلي تي شفٽ ڪندا آهيون ته جيئن، نسبتا ڳالهائڻ، اسان جو ڇهون سرور، جنهن کي اسين شامل ڪرڻ چاهيون ٿا، خالي جاءِ ۾ فٽ ٿئي، ۽ اسان ان کي اتي شامل ڪيو.
يقيناً اهڙي حالت ۾ ڪنجيون به ٻاهر نڪري وينديون آهن. پر اهي اڳ جي ڀيٽ ۾ تمام گهڻو ڪمزور نڪرندا آهن. ۽ اسان ڏسون ٿا ته اسان جون پهرين ٻه چاٻيون انهن جي سرورن تي رهيون آهن، ۽ ڪيشنگ سرور صرف آخري ڪنجي لاءِ تبديل ٿيو. اهو ڪم ڪافي ڪارائتو آهي، ۽ جيڪڏهن توهان نوان لشڪر وڌو ٿا، ته پوءِ هتي ڪو وڏو مسئلو ناهي. توھان شامل ڪريو ۽ ھڪڙي وقت ۾ ٿورڙو شامل ڪريو، انتظار ڪريو جيستائين ڪيش مڪمل ٿي وڃي، ۽ سڀ ڪجھ ٺيڪ ڪم ڪري ٿو.
رڳو سوال رهي ٿو انڪار سان. اچو ته فرض ڪريو ته ڪار جي ڪجهه قسم جي حڪم کان ٻاهر آهي.
۽ اسان واقعي نه ٿا چاهيون ته هن نقشي کي هن وقت ٻيهر ٺاهيو، ڪيش جو حصو غلط ڪيو، وغيره، جيڪڏهن، مثال طور، مشين کي ريبوٽ ڪيو ويو، ۽ اسان کي ڪنهن به طرح خدمت جي درخواستن جي ضرورت آهي. اسان صرف هر سائيٽ تي هڪ بيڪ اپ فوٽو ڪيش رکون ٿا، جيڪو ڪنهن به مشين جي متبادل طور ڪم ڪري ٿو جيڪا هن وقت بند آهي. ۽ جيڪڏهن اوچتو اسان جو هڪ سرور دستياب نه ٿي وڃي، ٽرئفڪ اتي وڃي ٿي. قدرتي طور تي، اسان وٽ ڪو به ڪيش نه آهي، يعني. اهو ٿڌو آهي، پر گهٽ ۾ گهٽ صارف جي درخواستن تي عمل ڪيو پيو وڃي. جيڪڏهن اهو هڪ مختصر وقفو آهي، ته پوء اسان ان کي مڪمل طور تي آرام سان تجربو ڪيو. اسٽوريج تي صرف وڌيڪ لوڊ آهي. جيڪڏهن اهو وقفو ڊگهو آهي، ته پوءِ اسان اڳ ۾ ئي فيصلو ڪري سگهون ٿا - هن سرور کي نقشي مان هٽائڻ يا نه، يا شايد ان کي ڪنهن ٻئي سان مٽايو.
هي ڪيشنگ سسٽم بابت آهي. اچو ته نتيجن کي ڏسو.
اهو لڳي ٿو ته هتي ڪجھ به پيچيده ناهي. پر ڪيش کي منظم ڪرڻ جو هي طريقو اسان کي اٽڪل 98٪ جي چال جي شرح ڏني. اهي. انهن 80 هزار درخواستن مان في سيڪنڊ، صرف 1600 اسٽوريج تائين پهچن ٿا، ۽ اهو هڪ مڪمل طور تي عام لوڊ آهي، اهي آرام سان برداشت ڪن ٿا، اسان وٽ هميشه هڪ رزرو آهي.
اسان انهن سرورن کي اسان جي ٽن ڊي سيز ۾ رکيو، ۽ ٽي پوائنٽس جي موجودگي حاصل ڪئي - پراگ، مامي ۽ هانگ ڪانگ.
اهو. اهي گهٽ يا گهٽ مقامي طور تي اسان جي هر ٽارگيٽ مارڪيٽ ۾ واقع آهن.
۽ هڪ سٺي بونس جي طور تي، اسان کي هي ڪيشنگ پراکسي ملي ٿي، جنهن تي سي پي يو اصل ۾ بيڪار آهي، ڇاڪاڻ ته مواد جي خدمت ڪرڻ لاءِ اها ضرورت ناهي. ۽ اتي، NGINX + Lua استعمال ڪندي، اسان تمام گھڻو استعمال ڪندڙ منطق لاڳو ڪيو.
مثال طور، اسان ويب پي يا ترقي پسند jpeg سان تجربا ڪري سگهون ٿا (اهي موثر جديد فارميٽ آهن)، ڏسو ته اهو ڪيئن ٽريفڪ کي متاثر ڪري ٿو، ڪجهه فيصلا ڪري، ڪجهه ملڪن لاءِ ان کي فعال ڪري، وغيره. متحرڪ ريسائيز ڪريو يا اڏام تي فوٽو ڪڍو.
اهو هڪ سٺو استعمال جي صورت آهي جڏهن، مثال طور، توهان وٽ هڪ موبائل ايپليڪيشن آهي جيڪا تصويرون ڏيکاري ٿي، ۽ موبائل ايپليڪيشن هڪ وڏي تصوير جي درخواست ڪرڻ تي ڪلائنٽ جي سي پي يو کي ضايع ڪرڻ نه چاهيندو آهي ۽ پوء ان کي دٻائڻ لاء ان کي هڪ خاص سائيز ۾ تبديل ڪرڻ لاء. نظارو. اسان صرف متحرڪ طور تي وضاحت ڪري سگھون ٿا ڪجهه پيٽرولن کي UPort مشروط URL ۾، ۽ فوٽو ڪيش پاڻ کي تصوير کي تبديل ڪندو. ضابطي جي طور تي، اهو سائيز کي چونڊيو جيڪو اسان جسماني طور تي ڊسڪ تي آهي، ممڪن طور تي گهربل هڪ جي ويجهو، ۽ ان کي مخصوص ڪوآرڊينيٽس ۾ گھٽائي ڇڏيندو.
رستي ۾، اسان اعلي لوڊ سسٽم جي ڊولپرز جي ڪانفرنس جي گذريل پنجن سالن جي عوامي طور تي دستياب وڊيو رڪارڊنگ ڪئي آهي. . ڏسو، سکيو، شيئر ڪريو ۽ رڪنيت حاصل ڪريو .
اسان اتي پڻ ڪيترائي پراڊڪٽ منطق شامل ڪري سگھون ٿا. مثال طور، اسان URL پيٽرولر استعمال ڪندي مختلف واٽر مارڪ شامل ڪري سگھون ٿا، اسان ڦوٽو، بلور يا پکسليٽ ڪري سگھون ٿا. اهو تڏهن ٿيندو آهي جڏهن اسان ڪنهن ماڻهوءَ جي تصوير ڏيکارڻ چاهيون ٿا، پر اسان ان جو چهرو نه ڏيکارڻ چاهيون، اهو سٺو ڪم ڪري ٿو، اهو سڀ هتي لاڳو ڪيو ويو آهي.
اسان کي ڇا مليو؟ اسان وٽ موجودگي جا ٽي نقطا، هڪ سٺي چال جي شرح، ۽ ساڳئي وقت اسان وٽ انهن مشينن تي بيڪار سي پي يو ناهي. هو هاڻي، يقينا، اڳ کان وڌيڪ اهم ٿي چڪو آهي. اسان کي پاڻ کي مضبوط ڪارٽون ڏيڻ جي ضرورت آهي، پر اهو ان جي لائق آهي.
هي تصويرن جي واپسي جو تعلق آهي. هتي هر شيء بلڪل صاف ۽ واضح آهي. مان سمجهان ٿو ته مون آمريڪا کي دريافت نه ڪيو آهي، تقريبن ڪنهن به سي ڊي اين هن طريقي سان ڪم ڪري ٿو.
۽، گهڻو ڪري، هڪ نفيس ٻڌندڙ کي شايد هڪ سوال هجي: ڇو نه صرف هر شي کي سي ڊي اين ۾ تبديل ڪيو وڃي؟ اهو ساڳيو ئي هوندو؛ سڀ جديد سي ڊي اينز اهو ڪري سگهن ٿا. ۽ اهڙا ڪيترائي سبب آهن.
پهرين تصوير آهي.
هي اسان جي انفراسٽرڪچر جي اهم نقطن مان هڪ آهي، ۽ اسان کي ان تي جيترو ٿي سگهي ڪنٽرول جي ضرورت آهي. جيڪڏهن اهو ڪنهن ٽئين پارٽي وينڊر کان حل آهي، ۽ توهان وٽ ان تي ڪا به طاقت نه آهي، اهو توهان لاءِ ان سان گڏ رهڻ ڪافي ڏکيو هوندو جڏهن توهان وٽ وڏو ڊيٽا سيٽ هوندو، ۽ جڏهن توهان وٽ تمام وڏو وهڪرو هوندو. استعمال ڪندڙ جي درخواستن جي.
اچو ته توهان کي هڪ مثال ڏيان. هاڻي، اسان جي انفراسٽرڪچر سان، اسان ڪري سگهون ٿا، مثال طور، ڪجهه مسئلن يا زير زمين دٻن جي صورت ۾، مشين ڏانهن وڃو ۽ اتي ڀرسان گندگي، نسبتا ڳالهائڻ. اسان ڪجھ ميٽرڪس جو مجموعو شامل ڪري سگھون ٿا جن جي اسان کي صرف ضرورت آھي، اسان ڪجھھ طريقي سان تجربو ڪري سگھون ٿا، ڏسو ته اھو گراف کي ڪيئن متاثر ڪري ٿو، وغيره. هاڻي هن ڪيشنگ ڪلسٽر تي ڪيترائي انگ اکر گڏ ڪيا پيا وڃن. ۽ اسان وقتي طور تي ان کي ڏسندا آهيون ۽ هڪ ڊگهو وقت گذاريندا آهيون ڪجهه بي ضابطگين کي ڳولڻ ۾. جيڪڏهن اهو CDN پاسي تي هئا، اهو ڪنٽرول ڪرڻ تمام گهڻو ڏکيو هوندو. يا، مثال طور، جيڪڏهن ڪنهن قسم جو حادثو ٿئي ٿو، اسان ڄاڻون ٿا ته ڇا ٿيو، اسان ڄاڻون ٿا ته ان سان ڪيئن رهڻو آهي ۽ ان تي قابو ڪيئن ڪجي. هي پهريون نتيجو آهي.
ٻيو نتيجو پڻ تاريخي آهي، ڇاڪاڻ ته اهو نظام هڪ ڊگهي وقت تائين ترقي ڪري رهيو آهي، ۽ مختلف مرحلن تي ڪيتريون ئي مختلف ڪاروباري گهرجون هيون، ۽ اهي هميشه سي ڊي اين جي تصور ۾ نه ٿا اچن.
۽ اھو نڪتو جيڪو پوئين ھڪڙي کان ھيٺ آھي
اهو ئي سبب آهي ته فوٽو ڪيچ تي اسان وٽ تمام گهڻو مخصوص منطق آهي، جيڪو هميشه درخواست تي شامل نه ٿو ڪري سگهجي. اهو ممڪن ناهي ته ڪو به CDN توهان جي درخواست تي ڪجهه ڪسٽم شيون شامل ڪندو. مثال طور، يو آر ايل کي انڪرپٽ ڪرڻ جيڪڏهن توهان نٿا چاهيو ته ڪلائنٽ ڪجهه تبديل ڪرڻ جي قابل ٿي وڃي. ڇا توھان سرور تي URL تبديل ڪرڻ چاھيو ٿا ۽ ان کي انڪرپٽ ڪريو، ۽ پوءِ ھتي ڪجھ متحرڪ پيٽرولر موڪليو.
اهو ڪهڙو نتيجو پيش ڪري ٿو؟ اسان جي حالت ۾، سي ڊي اين هڪ تمام سٺو متبادل ناهي.
۽ توهان جي صورت ۾، جيڪڏهن توهان وٽ ڪا خاص ڪاروباري گهرجون آهن، ته پوءِ توهان آساني سان عمل ڪري سگهو ٿا جيڪي مون توهان کي ڏيکاريو آهي. ۽ اهو ساڳيو لوڊ پروفائل سان مڪمل طور تي ڪم ڪندو.
پر جيڪڏهن توهان وٽ ڪجهه قسم جو عام حل آهي، ۽ اهو ڪم تمام خاص ناهي، توهان بلڪل محفوظ طور تي CDN وٺي سگهو ٿا. يا جيڪڏهن وقت ۽ وسيلا توهان لاءِ ڪنٽرول کان وڌيڪ اهم آهن.
۽ جديد سي ڊي اينز وٽ لڳ ڀڳ هر شيءِ آهي جنهن بابت مون توهان کي هاڻي ٻڌايو آهي. سواءِ پلس يا مائنس جي ڪجھ خصوصيتن جي.
هي تصويرون ڏيڻ بابت آهي.
اچو ته هاڻي اسان جي ماضي ۾ ٿورو اڳتي وڌون ۽ اسٽوريج بابت ڳالهايون.
2013 گذري ويو.
ڪيشنگ سرور شامل ڪيا ويا، ڪارڪردگي جا مسئلا پري ٿي ويا. سڀ ڪجھ ٺيڪ آهي. ڊيٽا سيٽ وڌي رهيو آهي. 2013 تائين، اسان وٽ اٽڪل 80 سرورز اسٽوريج سان ڳنڍيل هئا، ۽ هر DC ۾ اٽڪل 40 ڪيچنگ وارا. هي آهي 560 ٽيرا بائيٽ ڊيٽا جو هر ڊي سي تي، يعني. مجموعي طور تي هڪ petabyte جي باري ۾.
۽ ڊيٽا سيٽ جي واڌ سان، آپريٽنگ خرچن ۾ اضافو ٿيڻ لڳو. ان جو مطلب ڇا ٿيو؟
هن آريگرام ۾ جيڪو ٺهيل آهي - هڪ SAN سان، ان سان ڳنڍيل مشين ۽ ڪيچ سان - ناڪامي جا ڪيترائي نقطا آهن. جيڪڏهن اسان اڳ ۾ ئي اڳ ۾ ئي ڪيشنگ سرور جي ناڪامي سان معاملو ڪيو هو، هر شيء گهٽ يا گهٽ پيش گوئي ۽ سمجھڻ واري هئي، پر اسٽوريج جي پاسي تي هر شيء تمام خراب هئي.
پهرين، اسٽوريج ايريا نيٽورڪ (SAN) پاڻ، جيڪو ناڪام ٿي سگهي ٿو.
ٻيو، اهو آپٽڪس ذريعي آخري مشين سان ڳنڍيل آهي. نظرياتي ڪارڊ ۽ اسپارڪ پلگ سان مسئلا ٿي سگھن ٿا.
يقينن، انهن مان ڪيترا ئي نه آهن جيئن SAN پاڻ سان، پر، ان جي باوجود، اهي پڻ ناڪامي جا نقطا آهن.
اڳيون خود مشين آهي، جيڪو اسٽوريج سان ڳنڍيل آهي. اهو پڻ ناڪام ٿي سگهي ٿو.
مجموعي طور تي، اسان وٽ ناڪامي جا ٽي نقطا آهن.
ان کان سواء، ناڪامي جي پوائنٽن کان علاوه، اسٽوريج جي وڏي سار سنڀال آهي.
اهو هڪ پيچيده ملٽي اجزاء وارو نظام آهي، ۽ سسٽم انجنيئرن کي ان سان گڏ ڪم ڪرڻ ڏکيو وقت حاصل ڪري سگهي ٿو.
۽ آخري، سڀ کان اهم نقطو. جيڪڏهن انهن ٽن پوائنٽن مان ڪنهن به ناڪامي ٿئي ٿي، اسان وٽ صارف جي ڊيٽا کي وڃائڻ جو غير صفر موقعو آهي ڇو ته فائيل سسٽم خراب ٿي سگهي ٿو.
اچو ته اسان جو فائيل سسٽم ڀڄي ويو آهي. پهرين، ان جي وصولي هڪ ڊگهو وقت وٺندو آهي - ان کي ڊيٽا جي هڪ وڏي رقم سان هڪ هفتي وٺي سگهي ٿو. ۽ ٻيو، آخر ۾ اسان گهڻو ڪري ناقابل فهم فائلن جي هڪ گروپ سان ختم ڪنداسين جيڪي ڪنهن به طريقي سان صارف جي فوٽوز ۾ گڏ ٿيڻ جي ضرورت پوندي. ۽ اسان کي ڊيٽا وڃائڻ جو خطرو آهي. خطرو ڪافي بلند آهي. ۽ جيتري قدر اهڙيون حالتون ٿينديون آهن، ۽ جيترا وڌيڪ مسئلا هن سڄي زنجير ۾ پيدا ٿيندا آهن، اوترو اهو خطرو وڌيڪ هوندو آهي.
ان باري ۾ ڪجهه ڪرڻ گهرجي ها. ۽ اسان فيصلو ڪيو ته اسان کي صرف ڊيٽا کي بيڪ اپ ڪرڻ جي ضرورت آهي. اهو اصل ۾ هڪ واضح حل ۽ هڪ سٺو آهي. اسان ڇا ڪيو آهي؟
اھو اھو آھي جيڪو اسان جي سرور وانگر نظر ايندو ھو جڏھن اھو اڳي ئي اسٽوريج سان ڳنڍيل ھو. هي هڪ مکيه سيڪشن آهي، اهو صرف هڪ بلاڪ ڊيوائس آهي جيڪو اصل ۾ نظرياتي ذريعي ريموٽ اسٽوريج لاءِ جبل جي نمائندگي ڪري ٿو.
اسان صرف هڪ ٻيو حصو شامل ڪيو.
اسان ان جي اڳيان هڪ سيڪنڊ اسٽوريج رکيا (خوشقسمتي سان، اهو پئسن جي لحاظ کان قيمتي نه آهي)، ۽ ان کي هڪ بيڪ اپ ورهاڱي سڏيو. اهو پڻ آپٽڪس ذريعي ڳنڍيل آهي ۽ ساڳئي مشين تي واقع آهي. پر اسان کي ڪنهن به طرح انهن جي وچ ۾ ڊيٽا کي هم وقت سازي ڪرڻ جي ضرورت آهي.
هتي اسان صرف ويجھو هڪ غير مطابقت واري قطار ٺاهيندا آهيون.
هوء ڏاڍي مصروف نه آهي. اسان ڄاڻون ٿا ته اسان وٽ ڪافي رڪارڊ نه آهن. هڪ قطار صرف MySQL ۾ هڪ ٽيبل آهي جنهن ۾ "توهان کي هن تصوير کي بيڪ اپ ڪرڻ جي ضرورت آهي" وانگر لائينون لکيل آهن. ڪنهن به تبديلي يا اپلوڊ سان، اسان بنيادي ورهاڱي کان نقل ڪريون ٿا بيڪ اپ ۾ هڪ غير مطابقت رکندڙ يا صرف ڪجهه قسم جي پس منظر ورڪر کي استعمال ڪندي.
۽ اهڙيء طرح اسان وٽ هميشه ٻه مسلسل حصا آهن. جيتوڻيڪ هن سسٽم جو هڪ حصو ناڪام ٿئي ٿو، اسان هميشه هڪ بيڪ اپ سان مکيه ورهاڱي کي تبديل ڪري سگهون ٿا، ۽ هر شي ڪم ڪرڻ جاري رهندو.
پر انهي جي ڪري، پڙهڻ جو لوڊ تمام گهڻو وڌي ٿو، ڇاڪاڻ ته ... ڪلائنٽ کان علاوه جيڪي مکيه سيڪشن مان پڙهيا آهن، ڇاڪاڻ ته اهي پهريون ڀيرو فوٽو تي نظر اچن ٿا (اهو اتي تازو آهي)، ۽ پوء ان کي بيڪ اپ تي ڏسو، جيڪڏهن انهن کي اهو نه مليو آهي (پر NGINX صرف اهو ڪري ٿو)، اسان جو سسٽم پڻ هڪ پلس بيڪ اپ آهي هاڻي مکيه ورهاڱي مان پڙهي ٿو. اهو نه آهي ته اها هڪ رڪاوٽ هئي، پر مان لوڊ وڌائڻ نه چاهيندو هو، بنيادي طور تي، بس.
۽ اسان هڪ ٽيون ڊسڪ شامل ڪيو، جيڪو هڪ ننڍڙو SSD آهي، ۽ ان کي بفر سڏيو ويندو آهي.
اهو هاڻي ڪيئن ڪم ڪري ٿو.
صارف بفر تي هڪ فوٽو اپلوڊ ڪري ٿو، پوء هڪ واقعو قطار ۾ اڇلايو ويو آهي انهي مان ظاهر ٿئي ٿو ته ان کي ٻن حصن ۾ نقل ڪرڻ جي ضرورت آهي. اهو نقل ڪيو ويو آهي، ۽ تصوير ڪجهه وقت لاء بفر تي رهي ٿو (چئو، هڪ ڏينهن)، ۽ صرف ان کان پوء صاف ڪيو ويو آهي. اهو صارف جي تجربي کي تمام گهڻو بهتر بڻائي ٿو، ڇاڪاڻ ته صارف هڪ فوٽو اپ لوڊ ڪري ٿو، ضابطي جي طور تي، درخواستن کي فوري طور تي عمل ڪرڻ شروع ڪيو، يا هن پاڻ کي اپڊيٽ ڪيو ۽ ان کي تازو ڪيو. پر اهو سڀ تي منحصر آهي ايپليڪيشن تي جيڪو اپلوڊ ڪري ٿو.
يا، مثال طور، ٻيا ماڻهو جن کي هن پاڻ کي ڏيکارڻ شروع ڪيو، فوري طور تي هن تصوير کان پوء درخواستون موڪليو. اهو اڃا تائين ڪيش ۾ نه آهي؛ پهرين درخواست تمام جلدي ٿئي ٿي. لازمي طور تي ساڳيو ئي فوٽو ڪيش مان. سست اسٽوريج هن ۾ شامل ناهي. ۽ جڏهن هڪ ڏينهن بعد ان کي صاف ڪيو ويندو آهي، اهو اڳ ۾ ئي اسان جي ڪيشنگ پرت تي ڪيش ٿيل آهي، يا گهڻو ڪري، ڪنهن کي به ان جي ضرورت ناهي. اهي. هتي استعمال ڪندڙ جو تجربو تمام سٺو ٿي چڪو آهي اهڙين سادي ٺاهه جي ڪري.
خير، ۽ سڀ کان اهم: اسان ڊيٽا کي وڃائڻ بند ڪيو.
اچو ته بس چئون ته اسان روڪي ڇڏيو ممڪن طور ڊيٽا وڃايو، ڇو ته اسان واقعي ان کي نه وڃايو. پر اتي خطرو هو. اسان ڏسون ٿا ته اهو حل، يقينا، سٺو آهي، پر اهو ٿورڙو آهي جهڙوڪ مسئلي جي علامن کي صاف ڪرڻ، ان کي مڪمل طور تي حل ڪرڻ بدران. ۽ ڪجهه مسئلا هتي رهن ٿا.
پهرين ڳالهه ته اها ناڪاميءَ جو هڪ نقطو آهي جيڪو پاڻ جسماني ميزبان جي صورت ۾ آهي، جنهن تي هي سموري مشينري هلندي آهي؛ اها نه وئي آهي.
ٻيو ته اڃا تائين SAN جا مسئلا آهن، انهن جي سار سنڀال وغيره. اهو نه هو ته اهو هڪ نازڪ عنصر هو، پر مون چاهيو ته ڪنهن به طريقي سان ان جي بغير رهڻ جي ڪوشش ڪئي.
۽ اسان ٽيون نسخو ٺاهيو (حقيقت ۾، ٻيو اصل ۾) - رزرويشن نسخو. اهو ڇا نظر آيو؟
اهو ئي هو -
اسان جا بنيادي مسئلا ان حقيقت سان آهن ته هي هڪ جسماني ميزبان آهي.
پهرين، اسان SAN کي هٽائي رهيا آهيون ڇو ته اسان تجربو ڪرڻ چاهيون ٿا، اسان صرف مقامي هارڊ ڊرائيو کي آزمائي چاهيون ٿا.
اهو اڳ ۾ ئي 2014-2015 آهي، ۽ ان وقت ڊسڪ جي صورتحال ۽ هڪ ميزبان ۾ انهن جي گنجائش تمام گهڻو بهتر ٿي چڪو آهي. اسان فيصلو ڪيو ته ڇو نه ڪوشش ڪئي.
۽ پوء اسان صرف اسان جي بيڪ اپ ورهاڱي کي وٺو ۽ جسماني طور تي ان کي هڪ الڳ مشين ڏانهن منتقل ڪيو.
اهڙيء طرح، اسان کي هن تصوير حاصل ڪري. اسان وٽ ٻه ڪارون آهن جيڪي ساڳيون ڊيٽا سيٽون محفوظ ڪن ٿيون. اهي هڪ ٻئي کي مڪمل طور تي بيڪ اپ ڪن ٿا ۽ ساڳئي MySQL ۾ هڪ غير مطابقت واري قطار ذريعي نيٽ ورڪ تي ڊيٽا کي هم وقت سازي ڪن ٿا.
اهو ڇو سٺو ڪم ڪري ٿو ڇو ته اسان وٽ ڪجهه رڪارڊ آهن. اهي. جيڪڏهن لکڻ پڙهڻ جي مقابلي ۾ هجي ها ته شايد اسان وٽ ڪجهه قسم جا نيٽ ورڪ مٿي ۽ مسئلا هجن ها. ٿورڙي لکڻ، تمام گهڻو پڙهڻ - اهو طريقو سٺو ڪم ڪري ٿو، يعني. اسان گهٽ ۾ گهٽ انهن ٻن سرورن جي وچ ۾ فوٽو ڪاپي.
اهو ڪيئن ڪم ڪندو، جيڪڏهن توهان ٿورو وڌيڪ تفصيل سان ڏسو.
اپ لوڊ ڪريو. بيلنس صرف هڪ جوڙي سان بي ترتيب ميزبان کي چونڊيندو آهي ۽ ان تي اپ لوڊ ڪري ٿو. ساڳئي وقت، هو قدرتي طور تي صحت جي چڪاس ڪندو آهي ۽ يقيني بڻائي ٿو ته ڪار ٻاهر نه اچي. اهي. هو صرف هڪ لائيو سرور تي تصويرون اپلوڊ ڪري ٿو، ۽ پوءِ هڪ هم وقت ساز قطار ذريعي اهو سڀ سندس پاڙيسري ڏانهن نقل ڪيو ويو آهي. اپلوڊ ڪرڻ سان، هر شيء بلڪل سادو آهي.
ڪم ٿورو وڌيڪ ڏکيو آهي.
Lua هتي اسان جي مدد ڪئي، ڇاڪاڻ ته اهو وينلا اين جي اين ايڪس تي اهڙي منطق ٺاهڻ ڏکيو ٿي سگهي ٿو. اسان پهريون ڀيرو پهرين سرور کي درخواست ڪريون ٿا، ڏسو ته ڇا تصوير اتي آهي، ڇاڪاڻ ته ممڪن آهي ته اها اپلوڊ ٿي سگهي ٿي، مثال طور، هڪ پاڙيسري ڏانهن، پر اڃا تائين هتي نه آيو آهي. جيڪڏهن فوٽو اتي آهي، اهو سٺو آهي. اسان ان کي فوري طور تي ڪلائنٽ کي ڏيو ۽، ممڪن طور تي، ان کي ڪيش ڪريو.
جيڪڏهن اهو اتي نه آهي، اسان صرف پنهنجي پاڙيسري کي هڪ درخواست ڪريون ٿا ۽ ان کي اتان حاصل ڪرڻ جي ضمانت آهي.
اهو. ٻيهر اسان چئي سگهون ٿا: ڪارڪردگي سان مسئلا ٿي سگهن ٿا، ڇاڪاڻ ته اتي مسلسل گول سفر آهن - فوٽو اپ لوڊ ڪيو ويو، اهو هتي ناهي، اسان هڪ جي بدران ٻه درخواستون ڪري رهيا آهيون، اهو سست ڪم ڪرڻ گهرجي.
اسان جي صورتحال ۾، اهو سست ڪم نٿو ڪري.
اسان هن سسٽم تي ميٽرڪ جو هڪ گروپ گڏ ڪريون ٿا، ۽ اهڙي ميکانيزم جي مشروط سمارٽ شرح اٽڪل 95٪ آهي. اهي. هن بيڪ اپ جو وقفو ننڍڙو آهي، ۽ ان جي ڪري اسان تقريبن ضمانت آهيون، فوٽو اپ لوڊ ٿيڻ کان پوء، اسان ان کي پهريون ڀيرو کڻنداسين ۽ ٻه ڀيرا ڪٿي به وڃڻ جي ضرورت ناهي.
پوءِ اسان وٽ ٻيو ڇا آهي جيڪو واقعي سٺو آهي؟
اڳي، اسان وٽ مکيه بيڪ اپ ورهاڱو هو، ۽ اسان انهن مان ترتيب سان پڙهندا آهيون. اهي. اسان هميشه ڳولا ڪئي پهرين مکيه تي، ۽ پوءِ بيڪ اپ تي. اها هڪ حرڪت هئي.
ھاڻي اسان ھڪ ئي وقت ٻن مشينن مان پڙھڻ کي استعمال ڪريون ٿا. اسان گول رابن استعمال ڪندي درخواستون ورهايون ٿا. ڪيسن جي ٿورڙي سيڪڙو ۾ اسان ٻه درخواستون ڪيون ٿا. پر مجموعي طور تي، اسان وٽ هاڻي ٻه ڀيرا وڌيڪ پڙهڻ وارو اسٽاڪ آهي جيترو اسان وٽ اڳ هو. ۽ لوڊ تمام گهڻو گهٽجي ويو ٻنهي موڪلڻ واري مشينن تي ۽ سڌو سنئون اسٽوريج مشينن تي، جيڪو اسان وٽ ان وقت پڻ هو.
جيئن ته عيب رواداري لاء. حقيقت ۾، اهو آهي جيڪو اسان بنيادي طور تي وڙهندا آهيون. غلطي رواداري سان، هر شيء هتي عظيم نڪتو.
هڪ ڪار خراب ٿي.
ڪو مسئلو ناهي! سسٽم انجنيئر شايد رات جو به نه جاڳندو، هو صبح تائين انتظار ڪندو، ڪجهه به خراب نه ٿيندو.
جيڪڏھن ھيءَ مشين ناڪام ٿي وڃي ٿي، ته قطار بي ترتيب آھي، ڪو مسئلو به نه آھي، لاگ بس پھريائين رھڻ واري مشين تي جمع ڪيو ويندو، ۽ پوءِ ان کي قطار ۾ شامل ڪيو ويندو، ۽ پوءِ ڪار ڏانھن. ڪجهه وقت کان پوء آپريشن ۾ وڃو.
سار سنڀال سان ساڳي شيء. اسان صرف هڪ مشين کي بند ڪريون ٿا، دستي طور تي ان کي سڀني تلاءَ مان ڪڍون ٿا، اهو ٽريفڪ حاصل ڪرڻ بند ڪري ٿو، اسان ڪجهه قسم جي سار سنڀال ڪريون ٿا، اسان ڪجهه ترميم ڪريون ٿا، پوءِ اسان ان کي سروس تي واپس ڪريون ٿا، ۽ اهو بيڪ اپ تمام جلدي پڪڙي ٿو. اهي. في ڏينهن، هڪ ڪار جو بند وقت ڪجهه منٽن اندر پڪڙي ٿو. هي واقعي تمام ٿورڙو آهي. غلطي رواداري سان، مان ٻيهر چوان ٿو، هتي سڀ ڪجهه ٿڌو آهي.
هن فالتو اسڪيم مان ڪهڙا نتيجا ڪڍي سگهجن ٿا؟
اسان کي غلطي جي برداشت حاصل آهي.
استعمال ڪرڻ آسان. جيئن ته مشينن وٽ مقامي هارڊ ڊرائيو آهي، اهو ان سان گڏ ڪم ڪندڙ انجنيئرن لاءِ آپريشنل نقطي نظر کان وڌيڪ آسان آهي.
اسان کي ٻه ڀيرا پڙهڻ جو الائونس مليو.
هي هڪ تمام سٺو بونس آهي اضافي ۾ غلطي رواداري.
پر اتي به مسئلا آهن. هاڻي اسان وٽ ان سان لاڳاپيل ڪجهه خاصيتن جي وڌيڪ پيچيده ترقي آهي، ڇاڪاڻ ته اهو نظام 100٪ آخرڪار هڪجهڙائي بڻجي چڪو آهي.
اسان کي ضرور چوڻ گهرجي، ڪنهن پس منظر واري نوڪري ۾، مسلسل سوچڻ گهرجي: "هاڻي اسان ڪهڙي سرور تي هلائي رهيا آهيون؟"، "ڇا واقعي هتي موجوده تصوير آهي؟" وغيره اهو، يقينا، تمام لپي ويو آهي، ۽ پروگرامر لاء جيڪو لکي ٿو ڪاروباري منطق، اهو شفاف آهي. پر، ان جي باوجود، هن وڏي پيچيده پرت ظاهر ٿيو آهي. پر اسان ان کي برداشت ڪرڻ لاءِ تيار آهيون ان جي بدلي ۾ جيڪا اسان ان مان حاصل ڪئي.
۽ هتي وري ڪجهه تڪرار پيدا ٿئي ٿو.
مون شروع ۾ چيو ته مقامي هارڊ ڊرائيو تي هر شي کي محفوظ ڪرڻ خراب آهي. ۽ هاڻي مان چوان ٿو ته اسان ان کي پسند ڪيو.
ها، حقيقت ۾، وقت سان گڏ صورتحال تمام گهڻو تبديل ٿي چڪو آهي، ۽ هاڻي هن طريقي جا ڪيترائي فائدا آهن. پهرين، اسان کي تمام آسان آپريشن حاصل.
ٻيو، اهو وڌيڪ پيداوار آهي، ڇاڪاڻ ته اسان وٽ اهي خودڪار ڪنٽرولرز يا ڊسڪ شيلفز سان ڪنيڪشن نه آهن.
اتي مشينري جو تمام وڏو مقدار موجود آهي، ۽ اهي صرف چند ڊسڪ آهن جيڪي هتي مشين تي گڏ ڪيا ويا آهن.
پر اتي به نقصان آهن.
اهو لڳ ڀڳ 1,5 ڀيرا وڌيڪ مهانگو آهي SAN استعمال ڪرڻ جي ڀيٽ ۾ اڄ جي قيمتن تي. تنهن ڪري، اسان فيصلو ڪيو ته اسان جي سڄي وڏي ڪلستر کي مقامي هارڊ ڊرائيو سان ڪارن ۾ نه بدلايو ۽ هڪ هائبرڊ حل ڇڏڻ جو فيصلو ڪيو.
اسان جون اڌ مشينون هارڊ ڊرائيو سان ڪم ڪن ٿيون (چڱو، اڌ نه - شايد 30 سيڪڙو). ۽ باقي پراڻيون ڪارون آهن جن کي پهرين رزرويشن اسڪيم هوندي هئي. اسان صرف انهن کي ٻيهر نصب ڪيو، ڇو ته اسان کي نئين ڊيٽا يا ڪنهن ٻئي شيء جي ضرورت نه هئي، اسان صرف هڪ جسماني ميزبان کان ٻن ڏانهن منتقل ڪيو.
۽ هاڻي اسان وٽ پڙهڻ جو هڪ وڏو ذخيرو آهي، ۽ اسان ان کي وڌايو. جيڪڏهن اڳ ۾ اسان هڪ اسٽوريج تي هڪ مشين تي نصب ڪيو هو، هاڻي اسان چار نصب ڪيو، مثال طور، هڪ جوڙي تي. ۽ اهو سٺو ڪم ڪري ٿو.
اچو ته مختصر احوال وٺون ته اسان ڇا حاصل ڪيو، ڇا لاءِ وڙهون، ۽ ڇا اسان ڪامياب ٿياسين.
نتيجو
اسان وٽ استعمال ڪندڙ آهن - جيترو 33 ملين.
اسان وٽ موجود ٽي نقطا آهن - پراگ، مامي، هانگ ڪانگ.
انهن ۾ هڪ ڪيشنگ پرت آهي، جنهن ۾ ڪارن تي مشتمل آهي فاسٽ لوڪل ڊسڪ (SSDs)، جنهن تي NGINX کان سادي مشينري، ان جي access.log ۽ Python ڊيمون هلن ٿيون، جيڪي هن سڀني کي پروسيس ڪن ٿيون ۽ ڪيش کي منظم ڪن ٿيون.
جيڪڏھن توھان چاھيو ٿا، توھان پنھنجي پروجيڪٽ ۾ آھيو، جيڪڏھن تصويرون توھان لاءِ ايترا نازڪ نه آھن جيتري اھي اسان لاءِ آھن، يا جيڪڏھن ترقيءَ جي رفتار ۽ وسيلن جي قيمتن جي مقابلي ۾ واپار بند ڪنٽرول توھان لاءِ ٻئي طرف آھي، ته پوءِ توھان ان کي محفوظ طور تي تبديل ڪري سگھو ٿا. هڪ CDN سان، جديد CDN آهن اهي سٺو ڪم ڪن ٿا.
اڳيان اچي ٿو اسٽوريج پرت، جنهن تي اسان وٽ مشينن جي جوڙن جا ڪلستر آهن جيڪي هڪ ٻئي کي بيڪ اپ ڪن ٿا، فائلون هڪ کان ٻئي ڏانهن نقل ڪيون وينديون آهن جڏهن به اهي تبديل ٿينديون آهن.
ان کان علاوه، انهن مان ڪجهه مشينون مقامي هارڊ ڊرائيو سان ڪم ڪن ٿيون.
انهن مان ڪجهه مشينون SAN سان ڳنڍيل آهن.
۽، هڪ طرف، اهو استعمال ڪرڻ ۾ وڌيڪ آسان آهي ۽ ٿورو وڌيڪ پيداوار آهي، ٻئي طرف، اهو آسان آهي جڳهه جي کثافت ۽ قيمت في گيگا بائيٽ جي لحاظ کان.
هي هڪ مختصر جائزو آهي فن تعمير جو جيڪو اسان حاصل ڪيو ۽ اهو سڀ ڪيئن ترقي ڪيو.
ڪپتان کان ڪجھ وڌيڪ صلاحون، بلڪل سادو.
پهرين، جيڪڏهن توهان اوچتو فيصلو ڪيو ته توهان کي فوري طور تي توهان جي فوٽو انفراسٽرڪچر ۾ هر شي کي بهتر ڪرڻ جي ضرورت آهي، پهرين ماپ ڪريو، ڇاڪاڻ ته شايد ڪجهه به بهتر ٿيڻ جي ضرورت ناهي.
اچو ته توهان کي هڪ مثال ڏيان. اسان وٽ مشينن جو هڪ مجموعو آهي، جيڪا چٽس ۾ اٽيچمينٽ مان تصويرون موڪلي ٿي، ۽ اها اسڪيم اتي 2009 کان ڪم ڪري رهي آهي، ۽ ان ۾ ڪنهن کي به تڪليف نه ٿي آهي. هرڪو ٺيڪ آهي، هرڪو سڀ ڪجهه پسند ڪندو آهي.
ماپ ڪرڻ لاءِ، پھريائين ھڪڙي ميڙ کي لڪايو، انھن کي ڏسو، ۽ پوءِ فيصلو ڪريو ته توھان ڪھڙي شيءِ کان ناخوش آھيو ۽ ڪھڙي شيءِ کي سڌارڻ جي ضرورت آھي. ھن کي ماپڻ لاءِ، اسان وٽ ھڪڙو ٿڌو اوزار آھي جنھن کي پنبا سڏيو ويندو آھي.
اهو توهان کي NGINX کان تمام تفصيلي انگ اکر گڏ ڪرڻ جي اجازت ڏئي ٿو هر درخواست ۽ جوابي ڪوڊ، ۽ وقت جي تقسيم لاءِ - جيڪو توهان چاهيو ٿا. اهو سڀني قسمن جي مختلف تجزياتي سسٽم سان پابند آهي، ۽ پوء توهان ان کي تمام خوبصورت طور تي ڏسي سگهو ٿا.
پهرين اسان ان کي ماپ ڪيو، پوء اسان ان کي بهتر ڪيو.
اڳتي. اسان ڪيش سان پڙهڻ کي بهتر بڻائي، شارڊنگ سان لکڻ، پر اهو هڪ واضح نقطو آهي.
اڳتي. جيڪڏھن توھان ھاڻي شروع ڪري رھيا آھيو توھان جو سسٽم ٺاھيو، پوءِ اھو بھتر آھي ته تصويرن کي تبديل ڪرڻ واري فائلن وانگر. ڇو ته توهان فوري طور تي ڪيش جي غلطيءَ سان مسئلن جو هڪ پورو طبقو وڃائي ڇڏيو، انهي سان ته منطق کي تصوير جو صحيح نسخو ڪيئن ڳولڻ گهرجي، وغيره.
اچو ته چئو ته توهان هڪ سو اپ لوڊ ڪيو، پوء ان کي گھمايو، ان کي ٺاهيو ته اهو هڪ جسماني طور تي مختلف فائل هئي. اهي. سوچڻ جي ڪا ضرورت ناهي: ھاڻي مان ٿوري جاءِ بچائيندس، ان کي ساڳي فائل ۾ لکندس، ورجن تبديل ڪندس. اهو هميشه سٺو ڪم نٿو ڪري ۽ بعد ۾ تمام گهڻو سر درد پيدا ڪري ٿو.
ايندڙ نقطو. اڏام تي resize بابت.
اڳي، جڏهن صارفين هڪ فوٽو اپلوڊ ڪندا هئا، اسان فوري طور تي سڀني موقعن لاء، مختلف ڪلائنٽ لاء، ۽ اهي سڀئي ڊسڪ تي هئا. هاڻي اسان ان ڳالهه کي ڇڏي ڏنو آهي.
اسان صرف ٽي مکيه سائز ڇڏيا: ننڍو، وچولي ۽ وڏو. اسان صرف ان سائيز مان هر شيءِ کي هيٺ ڪريون ٿا جيڪو ان جي پويان آهي جيڪو اسان کي Uport تي چيو ويو هو، اسان صرف هيٺيون اسڪيل ڪندا آهيون ۽ صارف کي ڏيو.
هتي ڪيشنگ پرت جو سي پي يو تمام گهڻو سستو ٿي سگهي ٿو جيڪڏهن اسان مسلسل هر اسٽوريج تي انهن سائزن کي ٻيهر ٺاهيندا آهيون. اچو ته چئون ته اسان هڪ نئون شامل ڪرڻ چاهيون ٿا، ان ۾ هڪ مهينو لڳندو - هر جڳهه هڪ اسڪرپٽ هلايو جيڪو ڪلستر کي تباهه ڪرڻ کان سواءِ اهو سڀ ڪجهه صاف نموني سان ڪندو. اهي. جيڪڏھن توھان کي ھاڻي چونڊڻ جو موقعو آھي، اھو بھتر آھي ته جيترو ٿي سگھي ٿورڙو جسماني سائز ٺاھيو، پر انھيءَ لاءِ ته گھٽ ۾ گھٽ ڪجھ تقسيم، چئو، ٽي. ۽ باقي سڀ شيون آسانيءَ سان اڏامي سگھجن ٿيون تيار ڪيل ماڊلز استعمال ڪندي. اهو سڀ ڪجهه تمام آسان ۽ دستياب آهي هاڻي.
۽ واڌاري وارو هم وقتي بيڪ اپ سٺو آهي.
جيئن اسان جي مشق ڏيکاريل آهي، هي اسڪيم تبديل ٿيل فائلن جي دير سان ڪاپي ڪرڻ سان وڏو ڪم ڪري ٿو.
آخري نقطو پڻ واضح آهي. جيڪڏهن توهان جي انفراسٽرڪچر کي هاڻي اهڙا مسئلا نه آهن، پر اتي ڪجهه آهي جيڪو ٽوڙي سگهي ٿو، اهو ضرور ٽوڙيندو جڏهن اهو ٿورو وڌيڪ ٿيندو. تنهن ڪري، اهو بهتر آهي ته هن بابت اڳ ۾ سوچڻ ۽ ان سان مشڪلاتن جو تجربو نه ڪيو. اهو سڀ ڪجهه چوڻ چاهيان ٿو.
رابطو
»
»
هي رپورٽ اعلي لوڊ سسٽم جي ڊولپرز جي ڪانفرنس ۾ بهترين تقريرن مان هڪ نقل آهي . HighLoad++ 2017 ڪانفرنس تائين هڪ مهيني کان به گهٽ باقي آهي.
اسان وٽ اڳ ۾ ئي تيار آهي ، شيڊول هاڻي فعال طور تي ٺهيل آهي.
هن سال اسان آرڪيٽيڪچر ۽ اسڪيلنگ جي موضوع کي ڳولڻ جاري رکون ٿا:
- / Igor Vasiliev
- / دمتري ايگوروف
- / Anatoly Plaskovsky
- / رومن شيخووتسوف، اليڪسي گروماتچيڪوف
- / فلپ ڊيلگادو
اسان انهن مان ڪجھ مواد پڻ استعمال ڪريون ٿا اسان جي آن لائين تربيتي ڪورس ۾ اعلي لوڊ سسٽم کي ترقي ڪرڻ تي خاص طور تي چونڊيل خطن، مضمونن، مواد، وڊيوز جو هڪ سلسلو آهي. اسان جو درسي ڪتاب اڳ ۾ ئي 30 کان وڌيڪ منفرد مواد تي مشتمل آهي. ڳنڍيو!
جو ذريعو: www.habr.com