VKontakte جي فن تعمير ۽ ڪم تي FAQ

VKontakte جي پيدائش جي تاريخ وڪيپيڊيا تي آهي؛ اهو پاڻ Pavel طرفان ٻڌايو ويو هو. اهو لڳي ٿو ته هرڪو هن کي ڄاڻي ٿو. HighLoad++ Pavel تي سائيٽ جي اندروني، فن تعمير ۽ ساخت بابت مون کي 2010 ۾ واپس ٻڌايو. ان کان پوءِ ڪيترائي سرور لڪي ويا آهن، تنهن ڪري اسان معلومات کي اپڊيٽ ڪنداسين: اسان ان کي ڌار ڪنداسين، اندريون ٻاهر ڪڍنداسين، ان جو وزن، ۽ وي ڪي ڊوائيس کي ٽيڪنيڪل نقطي نظر کان ڏسو.

Alexey Akulovich (AterCattus) پس منظر ڊولپر VKontakte ٽيم ۾. هن رپورٽ جي ٽرانسڪرپٽ پليٽ فارم جي آپريشن، انفراسٽرڪچر، سرورز ۽ انهن جي وچ ۾ رابطي بابت اڪثر پڇيا ويا سوالن جو هڪ اجتماعي جواب آهي، پر ترقي بابت نه، يعني. لوهه جي باري ۾. الڳ الڳ، ڊيٽابيس بابت ۽ ان جي بدران VK ڇا آهي، لاگ گڏ ڪرڻ ۽ مجموعي طور تي سڄي منصوبي جي نگراني ڪرڻ بابت. ڪٽ جي هيٺان تفصيل.

چئن سالن کان وڌيڪ عرصي کان آئون پس منظر سان لاڳاپيل سڀني قسمن جي ڪمن سان معاملو ڪري رهيو آهيان.

• اپ لوڊ ڪرڻ، اسٽوريج، پروسيسنگ، ميڊيا کي ورهائڻ: وڊيو، لائيو اسٽريمنگ، آڊيو، فوٽو، دستاويز.
• انفراسٽرڪچر، پليٽ فارم، ڊولپر مانيٽرنگ، لاگز، ريجنل ڪيش، سي ڊي اين، پروپرائيٽري RPC پروٽوڪول.
• خارجي خدمتن سان انضمام: پش نوٽيفڪيشن، خارجي لنڪ پارسنگ، آر ايس ايس فيڊ.
• مختلف سوالن سان ساٿين جي مدد ڪرڻ، جن جا جواب اڻڄاتل ڪوڊ ۾ ڊائيونگ جي ضرورت آهي.

هن عرصي دوران، مون کي سائيٽ جي ڪيترن ئي حصن ۾ هڪ هٿ هو. مان هن تجربي کي حصيداري ڪرڻ چاهيان ٿو.

عام فن تعمير

هر شي، معمول وانگر، هڪ سرور يا سرور جي گروپ سان شروع ٿئي ٿو جيڪي درخواستون قبول ڪن ٿا.

سامهون سرور

اڳيون سرور HTTPS، RTMP ۽ WSS ذريعي درخواستون قبول ڪري ٿو.

اي ٽي پي پي - اهي درخواستون سائيٽ جي مکيه ۽ موبائل ويب ورزن لاءِ آهن: vk.com ۽ m.vk.com، ۽ اسان جي API جا ٻيا سرڪاري ۽ غير سرڪاري ڪلائنٽ: موبائل ڪلائنٽ، ميسينجر. اسان وٽ هڪ استقبال آهي آر ايل ايم پي- ٽريفڪ لائيو نشريات لاءِ الڳ فرنٽ سرورز ۽ WSS- اسٽريمنگ API لاءِ ڪنيڪشن.

سرورز تي HTTPS ۽ WSS لاءِ اھو قابل آھي نگنڪس. RTMP براڊڪاسٽس لاءِ، اسان تازو ئي تبديل ڪيو آھي پنھنجي حل تي kive، پر اها رپورٽ جي دائري کان ٻاهر آهي. غلطي رواداري لاءِ، اهي سرور عام IP پتي جو اشتهار ڏين ٿا ۽ گروپن ۾ ڪم ڪن ٿا ته جيئن ڪنهن هڪ سرور تي مسئلو هجي، صارف جون درخواستون گم نه ٿين. HTTPS ۽ WSS لاءِ، اهي ساڳيا سرور ٽريفڪ کي انڪرپٽ ڪن ٿا ته جيئن پاڻ تي سي پي يو لوڊ جو حصو وٺن.

اسان WSS ۽ RTMP بابت وڌيڪ نه ڳالهائينداسين، پر صرف معياري HTTPS درخواستن بابت، جيڪي عام طور تي ويب پروجيڪٽ سان لاڳاپيل آهن.

Backend

سامهون جي پويان عام طور تي پس منظر سرور آهن. اهي درخواستن تي عمل ڪن ٿيون جيڪي فرنٽ سرور گراهڪن کان وصول ڪن ٿيون.

هن kPHP سرورز, جنهن تي HTTP ڊيمون هلندي آهي، ڇاڪاڻ ته HTTPS اڳ ۾ ئي ڊريڪٽ ٿيل آهي. kPHP هڪ سرور آهي جيڪو هلندو آهي prefork ماڊلز: هڪ ماسٽر پروسيس شروع ٿئي ٿو، ٻارن جي عملن جو هڪ گروپ، انهن کي ٻڌڻ جي ساکٽ پاس ڪري ٿو ۽ اهي انهن جي درخواستن تي عمل ڪن ٿا. انهي صورت ۾، عملن کي صارف جي هر درخواست جي وچ ۾ ٻيهر شروع نه ڪيو ويو آهي، پر صرف انهن جي رياست کي اصل صفر-قيمت رياست ڏانهن ري سيٽ ڪيو - درخواست کان پوء درخواست، ٻيهر شروع ڪرڻ بدران.

لوڊ ورهائڻ

اسان جا سڀئي پس منظر مشينن جو هڪ وڏو تلاءُ نه آهن جيڪي ڪنهن به درخواست تي عمل ڪري سگهن. اسان انهن کي جدا جدا گروپن ۾ ورهايل: General, mobile, api, video, staging... مشينن جي الڳ گروپ تي مسئلو ٻين سڀني کي متاثر نه ڪندو. وڊيو سان مسئلن جي صورت ۾، صارف جيڪو موسيقي ٻڌندو آهي ان جي مسئلن جي باري ۾ به خبر ناهي. ڪهڙي پس منظر کي درخواست موڪلڻ جو فيصلو ڪيو ويو آهي nginx ترتيب جي مطابق فرنٽ تي.

ميٽرڪ گڏ ڪرڻ ۽ ٻيهر توازن

اهو سمجهڻ لاءِ ته اسان کي هر گروپ ۾ ڪيترين ئي ڪارن جي ضرورت آهي، اسان QPS تي ڀروسو نه ڪريو. پس منظر مختلف آهن، انهن جون مختلف درخواستون آهن، هر درخواست ۾ QPS جي ڳڻپ جي مختلف پيچيدگي آهي. ان ڪري اسان اسان مڪمل طور تي سرور تي لوڊ جي تصور سان هلون ٿا - CPU ۽ perf تي.

اسان وٽ اهڙا هزارين سرور آهن. هر فزيڪل سرور هڪ kPHP گروپ هلائي ٿو سڀني ڪور کي ريسائيڪل ڪرڻ لاءِ (ڇاڪاڻ ته kPHP سنگل ٿريڊ آهي).

مواد سرور

سي ايس يا مواد سرور هڪ اسٽوريج آهي. CS ھڪڙو سرور آھي جيڪو فائلن کي ذخيرو ڪري ٿو ۽ اپلوڊ ٿيل فائلن ۽ سڀني قسمن جي پس منظر جي هم وقت سازي ڪمن کي پروسيس ڪري ٿو جيڪو مکيه ويب فرنٽ اينڊ ان کي تفويض ڪري ٿو.

اسان وٽ هزارين جسماني سرور آهن جيڪي فائلن کي محفوظ ڪن ٿا. صارفين کي فائلون اپلوڊ ڪرڻ پسند آهن، ۽ اسان انهن کي ذخيرو ڪرڻ ۽ حصيداري ڪرڻ پسند ڪندا آهيون. انهن مان ڪجهه سرور خاص pu/pp سرورز طرفان بند ٿيل آهن.

pu/pp

جيڪڏهن توهان VK ۾ نيٽ ورڪ ٽيب کوليو، توهان ڏٺو pu/pp.

pu/pp ڇا آهي؟ جيڪڏهن اسان هڪ کان پوءِ هڪ سرور بند ڪريون ٿا ته پوءِ بند ٿيل سرور تي فائل اپلوڊ ڪرڻ ۽ ڊائون لوڊ ڪرڻ جا ٻه آپشن آهن: سڌو سنئون через http://cs100500.userapi.com/path يا وچولي سرور ذريعي - http://pu.vk.com/c100500/path.

Pu فوٽو اپلوڊ جو تاريخي نالو آهي، ۽ پي پي فوٽو پراکسي آهي. اھو آھي، ھڪڙو سرور فوٽوز اپلوڊ ڪرڻ لاء آھي، ۽ ٻيو اپلوڊ ڪرڻ لاء آھي. هاڻي نه رڳو تصويرون لوڊ ڪيون ويون آهن، پر نالو محفوظ ڪيو ويو آهي.

اهي سرور HTTPS سيشن ختم ڪريواسٽوريج مان پروسيسر لوڊ کي هٽائڻ لاء. انهي سان گڏ، جيئن ته صارف فائلون انهن سرورن تي پروسيس ٿيل آهن، انهن مشينن تي محفوظ ٿيل گهٽ حساس معلومات، بهتر. مثال طور، HTTPS انڪرپشن ڪيز.

جيئن ته مشينون اسان جي ٻين مشينن طرفان بند ٿيل آهن، اسان انهن کي "اڇو" خارجي IPs نه ڏيڻ جي متحمل ڪري سگهون ٿا، ۽ ڏيو "گرين". هن طريقي سان اسان IP پول تي محفوظ ڪيو ۽ مشينن کي ٻاهرئين پهچ کان بچائڻ جي ضمانت ڏني - ان ۾ داخل ٿيڻ لاءِ ڪو به IP ناهي.

حصيداري IPs تي استحڪام. غلطي رواداري جي لحاظ کان، اسڪيم ساڳيو ڪم ڪري ٿو - ڪيترن ئي جسماني سرورن وٽ هڪ عام فزيڪل IP آهي، ۽ انهن جي اڳيان هارڊويئر چونڊيندو آهي جتي درخواست موڪلڻ لاء. مان بعد ۾ ٻين اختيارن بابت ڳالهائيندس.

اختلافي نقطو اهو آهي ته هن معاملي ۾ ڪلائنٽ گهٽ ڪنيڪشن رکي ٿو. جيڪڏهن ڪيترن ئي مشينن لاءِ هڪ ئي IP آهي - ساڳئي ميزبان سان: pu.vk.com يا pp.vk.com، ڪلائنٽ برائوزر وٽ هڪ ميزبان جي هڪ ئي وقت درخواستن جي تعداد تي حد آهي. پر عام طور تي HTTP/2 جي وقت ۾، مان سمجهان ٿو ته اهو هاڻي ايترو لاڳاپيل ناهي.

منصوبي جو واضح نقصان اهو آهي ته اهو آهي تمام ٽرئفڪ پمپ، جيڪو اسٽوريج ڏانهن وڃي ٿو، ٻئي سرور ذريعي. جيئن ته اسان ٽريفڪ کي مشين ذريعي پمپ ڪريون ٿا، اسان اڃا تائين بھاري ٽريفڪ پمپ نٿا ​​ڪري سگھون، مثال طور، وڊيو، ساڳي اسڪيم استعمال ڪندي. اسان ان کي سڌو سنئون منتقل ڪريون ٿا - هڪ الڳ سڌو ڪنيڪشن الڳ الڳ اسٽوريج لاء خاص طور تي وڊيو لاء. اسان لائٽر مواد کي پراکسي ذريعي منتقل ڪندا آهيون.

گهڻو وقت اڳ اسان کي پراکسي جو هڪ بهتر نسخو مليو. هاڻي مان توهان کي ٻڌايان ٿو ته اهي عام ماڻهن کان ڪيئن مختلف آهن ۽ اهو ڇو ضروري آهي.

سج

سيپٽمبر 2017 ۾، Oracle، جيڪو اڳ ۾ سج خريد ڪيو هو، سن جي ملازمن جي وڏي تعداد کي برطرف ڪيو. اسان اهو چئي سگهون ٿا ته هن وقت ڪمپني جو وجود ختم ٿي ويو. جڏهن نئين سسٽم لاء نالو چونڊيو، اسان جي منتظمين هن ڪمپني جي يادگيري کي خراج تحسين پيش ڪرڻ جو فيصلو ڪيو ۽ نئين سسٽم جو نالو سج رکيو. پاڻ ۾ اسان هن کي صرف "سورج" سڏيندا آهيون.

pp ڪجھ مسئلا هئا. هڪ IP في گروپ - غير موثر ڪيش. ڪيترائي جسماني سرور ھڪڙي عام IP پتي کي حصيداري ڪندا آھن، ۽ ڪنٽرول ڪرڻ جو ڪو طريقو نه آھي جنھن سرور ڏانھن درخواست ويندي. ان ڪري، جيڪڏهن مختلف صارف هڪ ئي فائل لاءِ اچن ٿا، پوءِ جيڪڏهن انهن سرورن تي ڪيش آهي، ته فائل هر سرور جي ڪيش ۾ ختم ٿي ويندي آهي. هي هڪ انتهائي غير موثر اسڪيم آهي، پر ڪجهه به نه ٿي سگهيو.

نتيجتن - اسان مواد شيئر نٿا ڪري سگهون، ڇاڪاڻ ته اسان هن گروپ لاءِ مخصوص سرور نه چونڊي سگهون ٿا - انهن وٽ هڪ عام IP آهي. ڪجھ اندروني سببن لاء پڻ اسان وٽ آھي علائقن ۾ اهڙن سرورن کي انسٽال ڪرڻ ممڪن نه هو. اهي صرف سينٽ پيٽرسبرگ ۾ بيٺا هئا.

سج سان، اسان چونڊ نظام کي تبديل ڪيو. هاڻي اسان وٽ آهي anycast رستي: متحرڪ رستو، ڪو به ڪاسٽ، خود چيڪ ڊيمون. هر سرور جو پنهنجو انفرادي IP آهي، پر هڪ عام سبنٽ. هر شي کي اهڙي طرح ترتيب ڏنو ويو آهي ته جيڪڏهن هڪ سرور ناڪام ٿئي ٿو، ٽرئفڪ خود بخود ساڳئي گروپ جي ٻين سرورن تي پکڙيل آهي. هاڻي اهو ممڪن آهي ته هڪ مخصوص سرور چونڊيو، ڪابه غير ضروري ڪيشنگ، ۽ اعتبار متاثر نه ٿيو.

وزن جي حمايت. هاڻي اسان ضرورت مطابق مختلف پاور جون مشينون لڳائي سگهون ٿا، ۽ پڻ، عارضي مسئلن جي صورت ۾، ڪم ڪندڙ "سج" جي وزن کي تبديل ڪري انهن تي لوڊ گھٽائي سگهون ٿا، ته جيئن اهي "آرام" ڪن ۽ ٻيهر ڪم ڪرڻ شروع ڪن.

مواد جي سڃاڻپ ذريعي شيئرنگ. شارڊنگ جي باري ۾ هڪ عجيب شيء: اسان عام طور تي مواد شارٽ ڪندا آهيون ته جيئن مختلف استعمال ڪندڙ ساڳيا "سج" ذريعي ساڳئي فائل ڏانهن وڃو ته جيئن انهن وٽ هڪ عام ڪيش هجي.

اسان تازو شروع ڪيو ”ڪلور“ ايپليڪيشن. هي هڪ لائيو براڊ ڪاسٽ ۾ هڪ آن لائن کوئز آهي، جتي ميزبان سوال پڇي ٿو ۽ صارف حقيقي وقت ۾ جواب ڏين ٿا، اختيارن جي چونڊ ڪندي. ايپ ۾ هڪ چيٽ آهي جتي صارف چيٽ ڪري سگهن ٿا. هڪ ئي وقت ۾ نشريات سان ڳنڍجي سگھي ٿو 100 هزار کان وڌيڪ ماڻهو. اهي سڀئي پيغام لکندا آهن جيڪي سڀني شرڪت ڪندڙن ڏانهن موڪليا ويا آهن، ۽ هڪ اوتار پيغام سان گڏ اچي ٿو. جيڪڏهن 100 هزار ماڻهو هڪ اوتار لاء هڪ "سج" ۾ اچن ٿا، پوء اهو ڪڏهن ڪڏهن ڪڪر جي پويان ڦري سگهي ٿو.

ساڳئي فائل لاءِ درخواستن جي ڀڃڪڙي کي منهن ڏيڻ لاءِ، اهو هڪ خاص قسم جي مواد لاءِ آهي جنهن کي اسان هڪ بيوقوف اسڪيم تي ڦيرايو آهي جيڪا فائلن کي علائقي ۾ موجود سڀني ”سورج“ ۾ پکيڙي ٿي.

اندر کان سج

nginx تي ريورس پراکسي، ڪيش يا ته رام ۾ يا تيز Optane/NVMe ڊسڪ تي. مثال: http://sun4-2.userapi.com/c100500/path - "سج" ڏانهن هڪ لنڪ، جيڪو چوٿين علائقي ۾ واقع آهي، ٻيو سرور گروپ. اهو رستو فائل بند ڪري ٿو، جيڪو جسماني طور تي سرور 100500 تي آهي.

ڪپڙا

اسان هڪ وڌيڪ نوڊ شامل ڪيو اسان جي تعميراتي اسڪيم ۾ - ڪيشنگ ماحول.

هيٺ ڏنل لي آئوٽ ڊراگرام آهي علائقائي ڪيش، انهن مان اٽڪل 20 آهن. اهي جڳهيون آهن جتي ڪيش ۽ "سج" واقع آهن، جيڪي پنهنجي ذريعي ٽرئفڪ کي ڪيش ڪري سگهن ٿا.

هي ملٽي ميڊيا مواد جي ڪيشنگ آهي؛ ڪوبه صارف ڊيٽا هتي محفوظ نه آهي - صرف ميوزڪ، وڊيو، فوٽو.

صارف جي علائقي کي طئي ڪرڻ لاء، اسان اسان گڏ ڪريون ٿا BGP نيٽ ورڪ اڳياڙين جو اعلان ڪيل علائقن ۾. واپسي جي صورت ۾، اسان کي پڻ جيوپي ڊيٽابيس کي پارس ڪرڻو پوندو جيڪڏهن اسان اڳي ئي پي پي کي نه ڳولي سگهون. اسان علائقي کي استعمال ڪندڙ جي IP ذريعي طئي ڪريون ٿا. ڪوڊ ۾، اسان صارف جي ھڪڙي يا وڌيڪ علائقن کي ڏسي سگھون ٿا - اھي پوائنٽون جن کي ھو جاگرافيائي طور تي ويجھو آھي.

ان کي ڪيئن ڪم ڪندو؟

اسان علائقي جي لحاظ کان فائلن جي مقبوليت کي شمار ڪريون ٿا. اتي ڪيترائي علائقائي ڪيش آھن جتي صارف واقع آھي، ۽ ھڪڙو فائل سڃاڻپ ڪندڙ - اسان ھن جوڙو وٺون ٿا ۽ ھر ڊائون لوڊ سان درجه بندي کي وڌايو.

ساڳئي وقت، ڊيمن - علائقن ۾ خدمتون - وقت بوقت API ڏانهن ايندا آهن ۽ چوندا آهن: "مان هڪ اهڙي ۽ اهڙي ڪيش آهيان، مون کي منهنجي علائقي ۾ سڀ کان وڌيڪ مشهور فائلن جي فهرست ڏيو جيڪي اڃا تائين مون تي نه آهن. ” API درجه بندي جي ترتيب سان ترتيب ڏنل فائلن جو هڪ گروپ پهچائي ٿو، ڊيمون انهن کي ڊائون لوڊ ڪري ٿو، انهن کي علائقن ڏانهن وٺي ٿو ۽ اتان فائلون پهچائي ٿو. اهو بنيادي فرق آهي pu/pp ۽ سن جي وچ ۾ ڪيچز مان: اهي فوري طور تي پنهنجي ذريعي فائل ڏين ٿا، جيتوڻيڪ اها فائل ڪيش ۾ نه آهي، ۽ ڪيش پهريان فائل کي پاڻ ڏانهن ڊائون لوڊ ڪري ٿو، ۽ پوء ان کي واپس ڏيڻ شروع ڪري ٿو.

هن معاملي ۾ اسان کي حاصل مواد صارفين جي ويجهو ۽ نيٽ ورڪ لوڊ کي ڦهلائڻ. مثال طور، صرف ماسڪو ڪيش مان اسان ورهايون ٿا 1 Tbit/s کان وڌيڪ چوٽي جي ڪلاڪن دوران.

پر مسئلا آهن - ڪيش سرور ربر نه آهن. سپر مشهور مواد لاء، ڪڏهن ڪڏهن اتي نه آهي ڪافي نيٽ ورڪ هڪ الڳ سرور لاء. اسان جا ڪيش سرور 40-50 Gbit/s آهن، پر اهڙو مواد آهي جيڪو مڪمل طور تي اهڙي چينل کي بند ڪري ٿو. اسان علائقي ۾ مشهور فائلن جي هڪ کان وڌيڪ ڪاپي جي اسٽوريج کي لاڳو ڪرڻ جي طرف وڌي رهيا آهيون. مون کي اميد آهي ته اسان ان کي سال جي آخر تائين لاڳو ڪنداسين.

اسان عام آرڪيٽيڪچر کي ڏٺو.

• فرنٽ سرور جيڪي درخواستون قبول ڪن ٿا.
• backends ته عمل جي درخواستن.
• اسٽوريج جيڪي ٻن قسمن جي پراکسيز طرفان بند ڪيا ويا آهن.
• علائقائي ڪيش.

هن تصوير مان ڇا غائب آهي؟ يقينن، ڊيٽابيس جنهن ۾ اسان ڊيٽا کي ذخيرو ڪندا آهيون.

ڊيٽابيس يا انجڻ

اسان انهن کي ڊيٽابيس نه سڏيندا آهيون، پر انجڻ - انجڻ، ڇاڪاڻ ته اسان وٽ عملي طور تي عام طور تي قبول ٿيل معني ۾ ڊيٽابيس نه آهي.

هي هڪ ضروري ماپ آهي. اهو ٿي چڪو آهي ڇاڪاڻ ته 2008-2009 ۾، جڏهن VK جي مقبوليت ۾ هڪ ڌماڪيدار واڌ هئي، پروجيڪٽ مڪمل طور تي MySQL ۽ Memcache تي ڪم ڪيو ۽ مسئلا هئا. MySQL کي حادثو ۽ فائلن کي خراب ڪرڻ پسند ڪيو ويو، جنهن کان پوء اهو بحال نه ٿيندو، ۽ Memcache آهستي آهستي ڪارڪردگي ۾ خراب ٿي ويو ۽ ٻيهر شروع ڪرڻو پيو.

اهو ظاهر ٿئي ٿو ته وڌندڙ مقبول منصوبي ۾ مسلسل اسٽوريج هئي، جيڪا ڊيٽا کي خراب ڪري ٿي، ۽ هڪ ڪيش، جيڪو سست ٿئي ٿو. اهڙين حالتن ۾، هڪ وڌندڙ منصوبي کي ترقي ڪرڻ ڏکيو آهي. اهو فيصلو ڪيو ويو ته ڪوشش ڪرڻ جي ڪوشش ڪئي وڃي ته انهن نازڪ شين کي ٻيهر لکڻ جي ڪوشش ڪئي وڃي جيڪا پروجيڪٽ اسان جي پنهنجي سائيڪلن تي مرکوز هئي.

حل ڪامياب ٿيو. اهو ڪرڻ جو هڪ موقعو هو، گڏوگڏ هڪ انتهائي گهربل، ڇاڪاڻ ته ان وقت اسڪيلنگ جا ٻيا طريقا موجود نه هئا. هتي ڊيٽابيس جو هڪ گروپ نه هو، NoSQL اڃا موجود نه هو، اتي صرف MySQL، Memcache، PostrgreSQL هئا - ۽ اهو ئي آهي.

يونيورسل آپريشن. ترقي اسان جي سي ڊولپرز جي ٽيم جي اڳواڻي ڪئي وئي ۽ هر شيء هڪ جهڙي انداز ۾ ڪيو ويو. انجڻ کان سواءِ، انهن سڀني وٽ لڳ ڀڳ ساڳي فائل فارميٽ هئي ڊسڪ تي لکيل، ساڳيا لانچ پيٽرولر، ساڳيءَ طرح سان پروسيس ٿيل سگنل، ۽ تقريباً ساڳيو ئي رويو ڪن حالتن ۽ مسئلن جي صورت ۾. انجڻ جي واڌ سان، منتظمين لاءِ سسٽم کي هلائڻ لاءِ آسان آهي - ڪو به زو نه آهي جنهن کي برقرار رکڻ جي ضرورت آهي، ۽ انهن کي هر نئين ٽئين پارٽي ڊيٽابيس کي ڪيئن هلائڻو آهي، جنهن کي جلدي ۽ آسانيءَ سان وڌائڻ ممڪن بڻايو. انهن جو تعداد.

انجڻين جا قسم

ٽيم ڪافي ڪجھ انجڻ لکيا. هتي صرف انهن مان ڪجهه آهن: دوست، اشارا، تصوير، ipdb، خط، فهرستون، لاگز، memcached، meowdb، خبرون، nostradamus، فوٽو، پبليڪيشن، pmemcached، sandbox، ڳولا، اسٽوريج، پسند، ڪم، ...

هر ڪم لاءِ جيڪو مخصوص ڊيٽا جي جوڙجڪ جي ضرورت آهي يا غير معمولي درخواستن تي عمل ڪري ٿو، سي ٽيم هڪ نئين انجڻ لکي ٿي. ڇو نه.

اسان وٽ هڪ الڳ انجڻ آهي يادگار، جيڪو باقاعده هڪ جهڙو آهي، پر سٺين شين جي هڪ گروپ سان، ۽ جيڪو سست نٿو ٿئي. ڪلڪ هائوس نه، پر اهو پڻ ڪم ڪري ٿو. الڳ الڳ دستياب pmcached - هي آهي مسلسل memcached، جيڪو ڊسڪ تي ڊيٽا پڻ محفوظ ڪري سگھي ٿو، ان کان علاوه، ريم ۾ فٽ ٿيڻ کان سواء، جيئن ٻيهر شروع ڪرڻ وقت ڊيٽا کي وڃائڻ نه گهرجي. انفرادي ڪمن لاءِ مختلف انجڻيون آھن: قطارون، لسٽون، سيٽون - سڀ ڪجھ جيڪو اسان جي منصوبي جي گھرج آھي.

ڪلستر

ڪوڊ جي نقطي نظر کان، انجڻ يا ڊيٽابيس کي پروسيس، ادارن، يا مثالن جي طور تي سوچڻ جي ڪا ضرورت ناهي. ڪوڊ خاص طور تي ڪلستر سان گڏ ڪم ڪري ٿو، انجڻ جي گروپن سان. ھڪڙو قسم في ڪلستر. اچو ته چوندا آهن ته هڪ memcached ڪلستر آهي - اهو صرف مشينن جو هڪ گروپ آهي.

ڪوڊ کي جسماني مقام، سائيز، يا سرور جو تعداد ڄاڻڻ جي ضرورت ناهي. هو هڪ خاص سڃاڻپ ڪندڙ استعمال ڪندي ڪلستر ڏانهن وڃي ٿو.

ھن ڪم ڪرڻ لاءِ، توھان کي ھڪڙو وڌيڪ ادارو شامل ڪرڻو پوندو جيڪو ڪوڊ ۽ انجڻ جي وچ ۾ واقع آھي. پراکسي.

RPC پراکسي

پراڪسي ڳنڍيندڙ بسجنهن تي لڳ ڀڳ سڄي سائيٽ هلندي آهي. ساڳئي وقت اسان وٽ آهي ڪابه خدمت دريافت ناهي - ان جي بدران، هن پراکسي لاء هڪ ترتيب آهي، جيڪو سڀني ڪلستر جي جڳهه ۽ هن ڪلستر جي سڀني حصن کي ڄاڻي ٿو. اھو اھو آھي جيڪو منتظمين ڪندا آھن.

پروگرامرز کي پرواه ناهي ته ڪيترو، ڪٿي ۽ ڪهڙي قيمت آهي - اهي صرف ڪلستر ڏانهن ويندا آهن. هي اسان کي تمام گهڻو اجازت ڏئي ٿو. جڏهن هڪ درخواست ملي ٿي، پراکسي درخواست کي ريڊائريڪٽ ڪري ٿو، ڄاڻڻ جتي - اهو پاڻ کي طئي ڪري ٿو.

انهي حالت ۾، پراکسي سروس جي ناڪامي جي خلاف تحفظ جو هڪ نقطو آهي. جيڪڏهن ڪجھ انجڻ سست ٿئي ٿو يا حادثو ٿئي ٿو، پوء پراکسي ان کي سمجهي ٿو ۽ ڪلائنٽ جي طرف مطابق جواب ڏيندو. اهو توهان کي وقت ختم ڪرڻ جي اجازت ڏئي ٿو - ڪوڊ انجڻ جو جواب ڏيڻ جو انتظار نٿو ڪري، پر سمجهي ٿو ته اهو ڪم نه ڪري رهيو آهي ۽ ڪجهه مختلف طريقي سان عمل ڪرڻ جي ضرورت آهي. ڪوڊ حقيقت لاء تيار ڪيو وڃي ته ڊيٽابيس هميشه ڪم نه ڪندا آھن.

مخصوص عمل درآمد

ڪڏهن ڪڏهن اسان واقعي چاهيون ٿا ته انجڻ جي طور تي ڪجهه قسم جو غير معياري حل آهي. ساڳئي وقت، اهو فيصلو ڪيو ويو ته اسان جي تيار ڪيل rpc-proxy کي استعمال نه ڪيو وڃي، خاص طور تي اسان جي انجڻ لاء، پر ڪم لاء هڪ الڳ پراکسي ٺاهڻ لاء.

MySQL لاءِ، جيڪو اسان وٽ اڃا تائين هتي ۽ اتي آهي، اسان استعمال ڪندا آهيون db-proxy، ۽ ClickHouse لاءِ. ڪتن جو گھر.

اهو عام طور تي هن طرح ڪم ڪري ٿو. اتي ھڪڙو خاص سرور آھي، اھو هلندو آھي kPHP، Go، Python - عام طور تي، ڪو به ڪوڊ جيڪو اسان جي RPC پروٽوڪول کي استعمال ڪري سگھي ٿو. ڪوڊ مقامي طور تي هڪ RPC پراکسي تي هلندو آهي - هر سرور جتي ڪوڊ واقع آهي ان جي پنهنجي مقامي پراکسي هلائي ٿو. درخواست تي، پراکسي سمجهي ٿو ته ڪٿي وڃي.

جيڪڏهن هڪ انجڻ ٻئي ڏانهن وڃڻ چاهي ٿي، جيتوڻيڪ اهو پاڙيسري هجي، پراکسي ذريعي وڃي ٿو، ڇاڪاڻ ته پاڙيسري ٻئي ڊيٽا سينٽر ۾ ٿي سگهي ٿو. انجڻ کي پاڻ کان سواءِ ڪنهن به شيءِ جي جڳهه کي ڄاڻڻ تي ڀروسو نه ڪرڻ گهرجي - اهو اسان جو معياري حل آهي. پر يقيناً اهڙا استثنا آهن :)

TL-اسڪيم جو هڪ مثال جنهن جي مطابق سڀئي انجڻ هلن ٿا.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

هي هڪ بائنري پروٽوڪول آهي، جنهن جو ويجهو ترين اينالاگ آهي protobuf اسڪيما اختياري فيلڊز، پيچيده قسمون - بلٽ ان اسڪالر جي توسيع، ۽ سوالن کي بيان ڪري ٿو. هر شي هن پروٽوڪول جي مطابق ڪم ڪري ٿي.

RPC مٿان TL مٿان TCP/UDP… UDP؟

اسان وٽ انجڻ جي درخواستن تي عمل ڪرڻ لاءِ آر پي سي پروٽوڪول آهي جيڪو TL اسڪيم جي چوٽي تي هلندو آهي. اهو سڀ ڪم ڪري ٿو TCP/UDP ڪنيڪشن تي. TCP سمجھ ۾ اچي ٿو، پر اسان کي اڪثر UDP جي ضرورت ڇو آھي؟

UDP مدد ڪري ٿو سرور جي وچ ۾ ڪنيڪشن جي وڏي تعداد جي مسئلي کان بچڻ. جيڪڏهن هر سرور وٽ هڪ RPC پراکسي آهي ۽، عام طور تي، اهو ڪنهن به انجڻ ڏانهن وڃي سگهي ٿو، پوءِ هر سرور تي هزارين TCP ڪنيڪشن آهن. اتي هڪ لوڊ آهي، پر اهو بيڪار آهي. UDP جي صورت ۾ اهو مسئلو موجود ناهي.

ڪابه بيڪار TCP هٿ ملائڻ. هي هڪ عام مسئلو آهي: جڏهن هڪ نئين انجڻ يا نئون سرور شروع ڪيو ويندو آهي، ڪيترائي TCP ڪنيڪشن هڪ ئي وقت قائم ٿيندا آهن. ننڍي ھلڪو وزن جي درخواستن لاء، مثال طور، يو ڊي پي پي لوڊ، ڪوڊ ۽ انجڻ جي وچ ۾ سڀ مواصلات آھي ٻه UDP پيڪيٽ: هڪ اڏام هڪ طرف، ٻيو ٻئي طرف. هڪ گول سفر - ۽ ڪوڊ انجڻ کان بغير ڪنهن هٿ ملائڻ کان جواب مليو.

ها، اهو سڀ صرف ڪم ڪري ٿو پيٽ جي نقصان جي تمام ننڍڙي سيڪڙو سان. پروٽوڪول کي ريٽرانسمٽس ۽ ٽائيم آئوٽ لاءِ سپورٽ آهي، پر جيڪڏهن اسان گهڻو ڪجهه وڃائي ويهون، ته اسان کي لڳ ڀڳ TCP ملندو، جيڪو فائديمند ناهي. اسان UDP کي ساگرن ۾ نه هلائيندا آهيون.

اسان وٽ اهڙا هزارين سرور آهن، ۽ اسڪيم ساڳي آهي: هر فزيڪل سرور تي انجڻ جو هڪ پيڪ نصب ٿيل آهي. اهي اڪثر ڪري سنگل ٿريڊ ٿيل آهن جيئن جلدي ممڪن طور تي بلاڪ ڪرڻ کان سواءِ هلائڻ لاءِ، ۽ هڪل ٿريڊ ٿيل حل طور شارڊ ٿيل آهن. ساڳئي وقت، اسان وٽ هنن انجڻين کان وڌيڪ قابل اعتماد ناهي، ۽ مسلسل ڊيٽا اسٽوريج تي تمام گهڻو ڌيان ڏنو ويندو آهي.

مسلسل ڊيٽا اسٽوريج

انجڻ binlogs لکندا آهن. هڪ binlog هڪ فائل آهي جنهن جي آخر ۾ رياست يا ڊيٽا ۾ تبديلي لاء هڪ واقعو شامل ڪيو ويندو آهي. مختلف حلن ۾ ان کي مختلف طور سڏيو ويندو آهي: بائنري لاگ، واال, اي او ايفپر اصول ساڳيو آهي.

انجڻ کي روڪڻ لاءِ ڪيترن ئي سالن تائين پوري binlog کي ٻيهر پڙهڻ کان پوءِ ٻيهر شروع ڪرڻ وقت انجڻ لکن ٿا تصوير - موجوده حالت. جيڪڏهن ضروري هجي ته، اهي پهريان ان مان پڙهندا آهن، ۽ پوءِ binlog مان پڙهڻ ختم ڪندا آهن. سڀئي binlogs هڪ ئي بائنري فارميٽ ۾ لکيل آهن - TL اسڪيم جي مطابق، ته جيئن منتظمين انهن کي پنهنجي اوزارن سان برابريءَ سان سنڀالي سگهن. تصويرن جي اهڙي ڪا ضرورت ناهي. هتي هڪ عام هيڊر آهي جيڪو ظاهر ڪري ٿو ته ڪنهن جو سنيپ شاٽ int آهي، انجڻ جو جادو، ۽ ڪهڙو جسم ڪنهن لاء اهم ناهي. اهو انجڻ سان مسئلو آهي جيڪو سنيپ شاٽ رڪارڊ ڪيو.

آئون جلدي آپريشن جي اصول کي بيان ڪندس. اتي ھڪڙو سرور آھي جنھن تي انجڻ ھلندي آھي. هو لکڻ لاءِ هڪ نئون خالي binlog کولي ٿو ۽ ان ۾ تبديلي لاءِ هڪ واقعو لکي ٿو.

ڪجهه نقطي تي، هو يا ته فيصلو ڪري ٿو پاڻ هڪ سنيپ شاٽ وٺڻ، يا هن کي سگنل ملي ٿو. سرور هڪ نئين فائل ٺاهي ٿو، ان ۾ ان جي پوري حالت لکي ٿو، موجوده binlog سائيز - offset - فائل جي آخر ۾ شامل ڪري ٿو، ۽ اڳتي لکڻ جاري رکي ٿو. هڪ نئون binlog ٺهيل نه آهي.

ڪجهه نقطي تي، جڏهن انجڻ ٻيهر شروع ٿيندي، اتي ڊسڪ تي هڪ binlog ۽ هڪ سنيپ شاٽ هوندو. انجڻ سڄو سنيپ شاٽ پڙهي ٿو ۽ پنهنجي حالت کي هڪ خاص نقطي تي وڌائي ٿو.

پڙهي ٿو پوزيشن جيڪا ان وقت هئي جيڪا سنيپ شاٽ ٺاهي وئي هئي ۽ بنلاگ جي سائيز.

موجوده حالت حاصل ڪرڻ لاءِ binlog جي پڇاڙيءَ کي پڙهو ۽ وڌيڪ واقعا لکڻ جاري رکي. هي هڪ سادي اسڪيم آهي؛ اسان جا سڀئي انجڻ ان مطابق ڪم ڪن ٿا.

ڊيٽا نقل

نتيجي طور، اسان ۾ ڊيٽا جي نقل بيان تي ٻڌل - اسان binlog ۾ لکون ٿا ڪا به صفحي جي تبديلي نه، پر نالو درخواستون تبديل ڪريو. بلڪل ملندڙ جلندڙ جيڪو نيٽ ورڪ تي اچي ٿو، صرف ٿورڙي تبديل ٿيل.

ساڳئي اسڪيم نه رڳو replication لاء استعمال ڪيو ويندو آهي، پر پڻ بيڪ اپ ٺاهڻ لاء. اسان وٽ هڪ انجڻ آهي - لکڻ جو ماسٽر جيڪو binlog ڏانهن لکندو آهي. ڪنهن ٻئي هنڌ جتي منتظمين ان کي سيٽ ڪيو، هي binlog نقل ڪيو ويو آهي، ۽ اهو ئي آهي - اسان وٽ هڪ بيڪ اپ آهي.

گھربل هجي پڙهڻ جو نقلسي پي يو پڙهڻ واري لوڊ کي گهٽائڻ لاءِ، پڙهڻ واري انجڻ کي آسانيءَ سان شروع ڪيو ويو آهي، جيڪو binlog جي پڇاڙيءَ کي پڙهي ٿو ۽ انهن حڪمن کي مقامي طور تي عمل ڪري ٿو.

هتان جي دير تمام ننڍڙي آهي، ۽ اهو معلوم ڪرڻ ممڪن آهي ته نقل ماسٽر جي پويان ڪيترو آهي.

RPC پراکسي ۾ ڊيٽا شارڊنگ

شارڊنگ ڪيئن ڪم ڪندو آهي؟ پراکسي ڪيئن سمجھي ٿي ته ڪھڙي ڪلستر شارڊ ڏانھن موڪليو وڃي؟ ڪوڊ نٿو چوي: "15 شارڊ لاء موڪليو!" - نه، اهو پراکسي طرفان ڪيو ويو آهي.

آسان ترين اسڪيم پهريون آهي - درخواست ۾ پهريون نمبر.

get(photo100_500) => 100 % N.

ھي ھڪڙو مثال آھي ھڪڙو سادي ميميچ ٿيل ٽيڪسٽ پروٽوڪول لاء، پر، يقينا، سوال پيچيده ۽ منظم ٿي سگھن ٿا. مثال سوال ۾ پهريون نمبر وٺندو آهي ۽ باقي جڏهن ڪلستر جي سائيز سان ورهايو ويندو آهي.

اهو مفيد آهي جڏهن اسان چاهيون ٿا ته هڪ واحد اداري جي ڊيٽا مقامي. اچو ته 100 هڪ صارف يا گروپ ID آهي، ۽ اسان چاهيون ٿا ته هڪ اداري جي سڀني ڊيٽا کي پيچيده سوالن لاء هڪ شارڊ تي هجي.

جيڪڏهن اسان کي پرواه ناهي ته درخواستون ڪلستر ۾ ڪيئن پکڙيل آهن، اتي هڪ ٻيو اختيار آهي - سڄي شارڊ کي ڌوئڻ.

hash(photo100_500) => 3539886280 % N

اسان کي هيش، ڊويزن جي باقي ۽ شارڊ نمبر پڻ ملي ٿي.

اهي ٻئي اختيار صرف ان صورت ۾ ڪم ڪندا جڏهن اسان ان حقيقت لاءِ تيار آهيون ته جڏهن اسان ڪلستر جي سائيز کي وڌائينداسين، اسان ان کي ورهائينداسين يا ان کي ڪيترائي ڀيرا وڌائينداسين. مثال طور، اسان وٽ 16 شارڊ هئا، اسان وٽ ڪافي نه آهي، اسان وڌيڪ چاهيون ٿا - اسان محفوظ طور تي حاصل ڪري سگهون ٿا 32 بغير وقت جي. جيڪڏهن اسان چاهيون ٿا ته وڌاءُ نه گھڻا، اتي وقت گھٽجي ويندو، ڇاڪاڻ ته اسان نقصان جي بغير هر شيءِ کي صحيح طرح ورهائي نه سگهنداسين. اهي اختيار مفيد آهن، پر هميشه نه.

جيڪڏهن اسان کي گهربل تعداد ۾ سرور شامل ڪرڻ يا ختم ڪرڻ جي ضرورت آهي، اسان استعمال ڪندا آهيون انگن اک لا ڪيتاما تي مسلسل هيشنگ. پر ساڳئي وقت، اسان ڊيٽا جي جڳهه کي مڪمل طور تي وڃائي ڇڏيو آهي؛ اسان کي درخواست کي ڪلستر ۾ ضم ڪرڻو پوندو ته جيئن هر ٽڪرا پنهنجو ننڍڙو جواب ڏئي، ۽ پوء پراکسي ۾ جوابن کي ملائي.

هتي سپر مخصوص درخواستون آهن. اهو هن طرح ڏسڻ ۾ اچي ٿو: RPC پراکسي درخواست وصول ڪري ٿي، اهو طئي ڪري ٿو ته ڪهڙي ڪلستر ڏانهن وڃو ۽ شارڊ کي طئي ڪري ٿو. پوءِ اتي يا ته لکڻ وارا ماسٽر آهن، يا، جيڪڏهن ڪلستر کي ريپليڪا سپورٽ آهي، اهو مطالبو تي هڪ نقل ڏانهن موڪلي ٿو. پراکسي اهو سڀ ڪجهه ڪري ٿو.

لاگز

اسان ڪيترن ئي طريقن سان لاگ لکندا آهيون. سڀ کان وڌيڪ واضح ۽ سادي آهي memcache تي لاگس لکو.

ring-buffer: prefix.idx = line

هتي هڪ اهم اڳڪٿي آهي - لاگ جو نالو، هڪ لڪير، ۽ اتي هن لاگ جي سائيز آهي - لائينن جو تعداد. اسان 0 کان قطارن جي تعداد تائين مائنس 1 تائين ھڪڙو بي ترتيب نمبر وٺون ٿا. ميمڪيچ ۾ ڪيئي ھڪڙو اڳيفڪس آھي جيڪو ھن بي ترتيب نمبر سان ڳنڍيل آھي. اسان لاگ لائن ۽ موجوده وقت کي قيمت تي بچايو.

جڏهن لاگ پڙهڻ لاء ضروري آهي، اسان کي کڻندا آهن ملٽي حاصل سڀ چابيون، وقت جي ترتيب سان، ۽ اهڙيء طرح حقيقي وقت ۾ پيداوار لاگ حاصل ڪريو. اهو اسڪيم استعمال ڪيو ويندو آهي جڏهن توهان کي حقيقي وقت ۾ پيداوار ۾ ڪجهه ڊيبگ ڪرڻ جي ضرورت آهي، بغير ڪنهن به شيء کي ٽوڙڻ جي، بغير ڪنهن کي روڪڻ يا ٻين مشينن ڏانهن ٽرئفڪ جي اجازت ڏيڻ جي، پر اهو لاگ ان ڊگهي نه آهي.

لاگن جي قابل اعتماد اسٽوريج لاءِ اسان وٽ هڪ انجڻ آهي لاگ انجڻ. اهو ئي سبب آهي ته اهو پيدا ڪيو ويو آهي ۽ وڏي پيماني تي ڪلستر جي وڏي تعداد ۾ استعمال ٿيندو آهي. سڀ کان وڏو ڪلسٽر جنهن کي مان ڄاڻان ٿو اسٽور 600 TB پيڪ ٿيل لاگز.

انجڻ تمام پراڻي آهي، اتي ڪلسٽر آهن جيڪي اڳ ۾ ئي 6-7 سال پراڻي آهن. ان سان گڏ مسئلا آهن جن کي اسان حل ڪرڻ جي ڪوشش ڪري رهيا آهيون، مثال طور، اسان لاگز کي محفوظ ڪرڻ لاءِ ڪلڪ هائوس کي فعال طور تي استعمال ڪرڻ شروع ڪيو.

ClickHouse ۾ لاگ گڏ ڪرڻ

هي ڊراگرام ڏيکاري ٿو ته اسان ڪيئن اسان جي انجڻ ۾ هلون ٿا.

اهو ڪوڊ آهي جيڪو مقامي طور تي وڃي ٿو RPC ذريعي RPC-proxy ڏانهن، ۽ اهو سمجهي ٿو ته انجڻ کي ڪٿي وڃڻو آهي. جيڪڏهن اسان ڪلڪ هائوس ۾ لاگ لکڻ چاهيون ٿا، اسان کي هن اسڪيم ۾ ٻه حصا تبديل ڪرڻ گهرجن:

• ڪلڪ هاؤس سان ڪجهه انجڻ کي تبديل ڪريو؛
• RPC پراکسي کي تبديل ڪريو، جيڪو ClickHouse تائين رسائي نٿو ڪري سگھي، ڪجھ حل سان جيڪو ڪري سگھي ٿو، ۽ RPC ذريعي.

انجڻ سادو آهي - اسان ان کي سرور سان تبديل ڪريون ٿا يا ڪلڪ هائوس سان سرور جي ڪلستر سان.

۽ ڪلڪ هائوس ڏانهن وڃڻ لاءِ، اسان ڪيو ڪتن جو گھر. جيڪڏهن اسان سڌو KittenHouse کان ClickHouse ڏانهن وڃون ٿا، اهو مقابلو نه ٿيندو. جيتوڻيڪ بغير درخواستن جي، اهو شامل ڪري ٿو HTTP ڪنيڪشن مان وڏي تعداد ۾ مشينن جي. ڪم ڪرڻ لاءِ اسڪيم لاءِ، سرور تي ClickHouse سان مقامي ريورس پراکسي وڌي وئي آهي، جيڪو اهڙي طرح لکيو ويو آهي ته اهو ڪنيڪشن جي گهربل مقدار کي برداشت ڪري سگهي ٿو. اهو پڻ پنهنجي اندر اندر ڊيٽا بفر ڪري سگهي ٿو نسبتا معتبر.

ڪڏهن ڪڏهن اسان غير معياري حلن ۾ RPC اسڪيم کي لاڳو ڪرڻ نٿا چاهيون، مثال طور، nginx ۾. تنهن ڪري، KittenHouse کي UDP ذريعي لاگ حاصل ڪرڻ جي صلاحيت آهي.

جيڪڏهن موڪليندڙ ۽ وصول ڪندڙ لاگ ان ساڳئي مشين تي ڪم ڪن ٿا، ته پوءِ مقامي ميزبان جي اندر UDP پيڪٽ وڃائڻ جو امڪان تمام گهٽ آهي. ٽين ڌر حل ۽ اعتبار ۾ RPC کي لاڳو ڪرڻ جي ضرورت جي وچ ۾ سمجھوتي جي طور تي، اسان صرف استعمال ڪريون ٿا UDP موڪلڻ. اسان هن اسڪيم کي بعد ۾ واپس ڪنداسين.

مانيٽرنگ

اسان وٽ لاگن جا ٻه قسم آهن: جيڪي ايڊمنسٽريٽرن پاران گڏ ڪيل آهن انهن جي سرورن تي ۽ اهي جيڪي ڊولپرز طرفان ڪوڊ مان لکيل آهن. اهي ٻه قسم جي ميٽرڪ سان ملن ٿا: سسٽم ۽ پيداوار.

سسٽم ميٽرڪ

اهو اسان جي سڀني سرورن تي ڪم ڪري ٿو نيٽٽا، جيڪو انگ اکر گڏ ڪري ٿو ۽ انهن کي موڪلي ٿو گرافائٽ ڪاربن. تنهن ڪري، ClickHouse هڪ اسٽوريج سسٽم طور استعمال ڪيو ويندو آهي، ۽ نه ويسپر، مثال طور. جيڪڏھن ضروري ھجي، توھان سڌو سنئون ڪلڪ ڪري سگھوٿا، يا استعمال ڪريو گرافانا ميٽرڪس، گراف ۽ رپورٽن لاء. ڊولپرز جي طور تي، اسان وٽ ڪافي رسائي آھي نيٽ ڊيٽا ۽ گرافانا.

پيداوار جي ماپ

سهولت لاءِ، اسان ڪافي شيون لکيون آهن. مثال طور، عام ڪمن جو هڪ سيٽ آهي جيڪو توهان کي انگن اکرن ۾ لکڻ جي اجازت ڏئي ٿو، منفرد ڳڻپ قدر، جيڪي ڪجهه اڳتي موڪليا ويا آهن.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

ان کان پوء، اسان استعمال ڪري سگھون ٿا ترتيب ۽ گروپنگ فلٽر ۽ سڀ ڪجھ ڪري سگھون ٿا جيڪو اسان انگن اکرن مان گھرون ٿا - گراف ٺاھيو، واچ ڊاگس ترتيب ڏيو.

اسان ڏاڍا لکندا آهيون ڪيترائي ميٽرڪ واقعن جو تعداد 600 بلين کان 1 ٽريلين في ڏينھن آھي. بهرحال، اسان ان کي رکڻ چاهيون ٿا گهٽ ۾ گهٽ ٻه سالميٽرڪ ۾ رجحانات کي سمجهڻ لاء. ان کي گڏ ڪرڻ هڪ وڏو مسئلو آهي جيڪو اسان اڃا تائين حل نه ڪيو آهي. مان توهان کي ٻڌايان ٿو ته اهو گذريل ڪجهه سالن کان ڪيئن ڪم ڪري رهيو آهي.

اسان وٽ اهي ڪم آهن جيڪي اهي ميٽرڪس لکندا آهن مقامي memcache ڏانهنداخلا جو تعداد گھٽائڻ لاء. هڪ ڀيرو ٿوري عرصي ۾ مقامي طور تي لانچ ڪيو ويو stats-daemon سڀ رڪارڊ گڏ ڪري ٿو. اڳيون، شيطان ميٽرڪس کي سرور جي ٻن تہن ۾ ضم ڪري ٿو لاگ گڏ ڪرڻ وارا، جيڪو اسان جي مشينن جي هڪ گروپ مان انگ اکر گڏ ڪري ٿو ته جيئن انهن جي پويان پرت مري نه وڃي.

جيڪڏهن ضروري هجي ته، اسان سڌو سنئون لاگ-ڪليڪٽرن ڏانهن لکي سگهون ٿا.

پر ڪوڊ کان سڌو سنئون ڪليڪٽرن ڏانهن لکڻ، اسٽاس-ڊيموم کي پاس ڪرڻ، هڪ خراب اسپيبلبل حل آهي ڇاڪاڻ ته اهو ڪليڪٽر تي لوڊ وڌائي ٿو. حل صرف مناسب آهي جيڪڏهن ڪنهن سبب جي ڪري اسان مشين تي memcache stats-daemon کي نه وڌائي سگهون ٿا، يا اهو تباهه ٿي ويو ۽ اسان سڌو ٿي ويا.

اڳيون، لاگ-ڪليڪٽرز انگن اکرن کي ضم ڪن ٿا meowDB - ھي آھي اسان جو ڊيٽابيس، جيڪو پڻ ذخيرو ڪري سگھي ٿو ميٽرڪ.

پوءِ اسان ڪوڊ مان بائنري ”نزد-SQL“ چونڊون ڪري سگھون ٿا.

تجربا

2018 جي ​​اونهاري ۾، اسان وٽ هڪ اندروني هيڪاٿون هو، ۽ خيال آيو ته آريگرام جي ڳاڙهي حصي کي تبديل ڪرڻ جي ڪوشش ڪئي وڃي جيڪا ڪلڪ هاؤس ۾ ميٽرڪ محفوظ ڪري سگهي ٿي. اسان وٽ ڪلڪ هاؤس تي لاگس آهن - ڇو نه ڪوشش ڪريو؟

اسان وٽ هڪ اسڪيم هئي جيڪا KittenHouse ذريعي لاگ لکندي هئي.

اسان فيصلو ڪيو ڊراگرام ۾ ٻيو "*House" شامل ڪريو, جنهن کي فارميٽ ۾ بلڪل ميٽرڪس وصول ڪندا جيئن اسان جو ڪوڊ انهن کي UDP ذريعي لکندو آهي. پوءِ هي *هائوس انهن کي داخلن ۾ بدلائي ٿو، جهڙوڪ لاگ، جنهن کي KittenHouse سمجهي ٿو. هو مڪمل طور تي انهن لاگن کي ClickHouse ڏانهن پهچائي سگهي ٿو، جيڪو انهن کي پڙهڻ جي قابل هوندو.

memcache، stats-daemon ۽ logs-collectors ڊيٽابيس سان گڏ اسڪيم کي ھن ھڪڙي سان تبديل ڪيو ويو آھي.

memcache، stats-daemon ۽ logs-collectors ڊيٽابيس سان گڏ اسڪيم کي ھن ھڪڙي سان تبديل ڪيو ويو آھي.

• هتي ڪوڊ مان هڪ ترسيل آهي، جيڪو مقامي طور تي StatsHouse ۾ لکيل آهي.
• StatsHouse UDP ميٽرڪس لکي ٿو، اڳ ۾ ئي SQL inserts ۾ تبديل ٿيل KittenHouse کي بيچ ۾.
• KittenHouse انھن کي ClickHouse ڏانھن موڪلي ٿو.
• جيڪڏهن اسان انهن کي پڙهڻ چاهيون ٿا، ته پوءِ اسين انهن کي پڙهون ٿا StatsHouse کان پاسو ڪندي - سڌو ClickHouse کان باقاعده SQL استعمال ڪندي.

ا stillا تائين آهي؟ تجربو، پر اسان پسند ڪيو ته اهو ڪيئن نڪتو. جيڪڏهن اسان اسڪيم سان مسئلا حل ڪريون ٿا، ته شايد اسان ان کي مڪمل طور تي تبديل ڪنداسين. ذاتي طور تي، مون کي اميد آهي.

هي منصوبو لوهه نه بچائيندو آهي. گھٽ سرورز جي ضرورت آھي، مقامي اسٽيٽس-ڊيمن ۽ لاگ-ڪليڪٽرز جي ضرورت نه آھي، پر ڪلڪ ھاؤس کي موجوده اسڪيم جي ڀيٽ ۾ وڏي سرور جي ضرورت آھي. ٿورڙا سرور جي ضرورت آهي، پر انهن کي وڌيڪ قيمتي ۽ وڌيڪ طاقتور هجڻ گهرجي.

مقرر ڪرڻ

پهرين، اچو ته ڏسو پي ايڇ پي جي ترتيب تي. اسان ۾ ترقي ڪري رهيا آهيون اٿي: استعمال GitLab и ٽيمڪٽي لڳائڻ لاء. ڊولپمينٽ شاخن کي ماسٽر برانچ ۾ ضم ڪيو ويو آهي، ماسٽر کان ٽيسٽنگ ۾ ضم ٿي ويا آهن، ۽ اسٽيجنگ کان پيداوار ۾.

ترتيب ڏيڻ کان اڳ، موجوده پيداوار جي شاخ ۽ پوئين ھڪڙي کي ورتو وڃي ٿو، ۽ مختلف فائلن کي انھن ۾ سمجھيو ويندو آھي - تبديليون: ٺاھيو، ختم ڪيو، تبديل ڪيو. اها تبديلي هڪ خاص ڪاپي فاسٽ انجڻ جي بن لاگ ۾ رڪارڊ ڪئي وئي آهي، جيڪا اسان جي سموري سرور فليٽ ۾ تبديلين کي جلدي نقل ڪري سگهي ٿي. هتي ڇا استعمال ڪيو ويو آهي سڌو نقل نه آهي، پر گپ شپ نقل، جڏهن هڪ سرور موڪلي ٿو تبديلين کي پنهنجي ويجهي پاڙيسرين ڏانهن، اهي انهن جي پاڙيسرين ڏانهن، وغيره. هي توهان کي ڪوڊ کي تازه ڪاري ڪرڻ جي اجازت ڏئي ٿو ڏهن ۽ سيڪنڊن جي يونٽن ۾ سڄي فليٽ ۾. جڏهن تبديلي مقامي ريپليڪا تائين پهچي ٿي، اهو انهن پيچ کي لاڳو ڪري ٿو مقامي فائيل سسٽم. Rollback به ساڳيو منصوبي جي مطابق ڪيو ويندو آهي.

اسان پڻ ڪي پي ايڇ پي کي تمام گهڻو ترتيب ڏيون ٿا ۽ ان جي پنهنجي ترقي پڻ آهي اٿي مٿي ڏنل تصوير جي مطابق. هن کان وٺي HTTP سرور بائنري، پوءِ اسان فرق پيدا نٿا ڪري سگھون - ڇڏڻ واري بائنري جو وزن سوين ايم بي آهي. تنهن ڪري، هتي هڪ ٻيو اختيار آهي - نسخو لکيو ويو آهي binlog ڪاپي فاسٽ. هر تعمير سان اهو وڌي ٿو، ۽ رول بيڪ دوران اهو پڻ وڌائي ٿو. نسخو سرورز ڏانهن نقل ٿيل. مقامي ڪاپي فاسٽ ڏسن ٿا ته هڪ نئون نسخو binlog ۾ داخل ٿيو آهي، ۽ ساڳئي گپ شپ جي نقل سان اهي پاڻ لاءِ بائنري جو جديد نسخو وٺي وڃن ٿا، اسان جي ماسٽر سرور کي ٿڪائڻ کان سواءِ، پر پوري نيٽ ورڪ تي لوڊشيڊنگ کي احتياط سان پکڙيل آهي. پٺيان ڇا شاندار ٻيهر لانچ نئين نسخي لاء.

اسان جي انجڻين لاء، جيڪي پڻ بنيادي طور تي بائنري آهن، اسڪيم بلڪل ساڳي آهي:

• git ماسٽر برانچ؛
• بائنري ۾ .deb;
• نسخو binlog copyfast ڏانهن لکيو ويو آهي؛
• سرور ڏانهن نقل ٿيل؛
• سرور هڪ تازو .dep ڪڍي ٿو.
• ڊي پي ڪلو -ا;
• نئين ورجن ڏانهن شاندار ٻيهر لانچ.

فرق اهو آهي ته اسان جي بائنري آرڪائيوز ۾ ڀريل آهي .deb، ۽ جڏهن اهي پمپ ڪري رهيا آهن ڊي پي ڪلو -ا سسٽم تي رکيل آهن. ڇو kPHP کي بائنري طور لڳايو ويو آهي، ۽ انجڻون dpkg طور تي لڳايو ويو آهي؟ ائين ئي ٿيو. اهو ڪم ڪري ٿو - ان کي هٿ نه ڪريو.

مددگار ڪڙيون:

• Anton Kiryushkin پاران رپورٽ "Vkontakte سسٽم ايڊمنسٽريٽر. ڪيئن؟" ڪاپي فاسٽ ۽ گپ شپ بابت تفصيل سان.
• رپورٽ Yuri Nasretdinov پاران "ڪيئن VK هزارين سرورن مان CLickHouse ۾ ڊيٽا داخل ڪري ٿو".
• منهنجي رپورٽ "VKontakte جي مثال کي استعمال ڪندي هڪ وڌندڙ منصوبي جي فن تعمير"، پر ترقي جي نقطي نظر کان، هارڊويئر نه.

Alexey Akulovich انهن مان هڪ آهي، جيڪو پروگرام ڪميٽي جي حصي جي طور تي مدد ڪري ٿو PHP روس 17 مئي تي پي ايڇ پي ڊولپرز لاءِ تازو وقتن ۾ سڀ کان وڏو واقعو بڻجي ويندو. ڏسو ته اسان وٽ هڪ بهترين پي سي آهي، ڇا ڳالهائيندڙ (انهن مان ٻه ترقي ڪري رهيا آهن PHP ڪور!) - لڳي ٿو ڪجهه توهان کي ياد نه ڪري سگهو جيڪڏهن توهان PHP لکو.

جو ذريعو: www.habr.com