🥇 فن تعمیر اور VKontakte پر کام کے بارے میں اکثر پوچھے گئے سوالات

VKontakte کی تخلیق کی تاریخ ویکیپیڈیا پر ہے؛ یہ خود Pavel کی طرف سے بتایا گیا تھا. ایسا لگتا ہے کہ ہر کوئی اسے پہلے ہی جانتا ہے۔ HighLoad++ Pavel پر سائٹ کے اندرونی، فن تعمیر اور ساخت کے بارے میں مجھے 2010 میں واپس کہا. اس کے بعد سے بہت سے سرورز لیک ہوچکے ہیں، اس لیے ہم معلومات کو اپ ڈیٹ کریں گے: ہم اسے ڈسیکٹ کریں گے، اندر سے باہر نکالیں گے، اس کا وزن کریں گے، اور VK ڈیوائس کو تکنیکی نقطہ نظر سے دیکھیں گے۔

الیکسی اکولووچ (ایٹر کیٹس) VKontakte ٹیم میں بیک اینڈ ڈویلپر۔ اس رپورٹ کا ٹرانسکرپٹ پلیٹ فارم کے آپریشن، انفراسٹرکچر، سرورز اور ان کے درمیان تعامل کے بارے میں اکثر پوچھے جانے والے سوالات کا ایک اجتماعی جواب ہے، لیکن ترقی کے بارے میں نہیں، یعنی لوہے کے بارے میں. علیحدہ طور پر، ڈیٹا بیس کے بارے میں اور اس کے بجائے VK کے پاس کیا ہے، لاگ جمع کرنے اور پورے پروجیکٹ کی مجموعی طور پر نگرانی کے بارے میں۔ کٹ کے نیچے تفصیلات۔

چار سال سے زیادہ عرصے سے میں پسدید سے متعلق ہر طرح کے کاموں سے نمٹ رہا ہوں۔

میڈیا کو اپ لوڈ کرنا، اسٹور کرنا، پروسیس کرنا، تقسیم کرنا: ویڈیو، لائیو اسٹریمنگ، آڈیو، تصاویر، دستاویزات۔
انفراسٹرکچر، پلیٹ فارم، ڈویلپر کی نگرانی، لاگز، علاقائی کیشز، CDN، ملکیتی RPC پروٹوکول۔
بیرونی خدمات کے ساتھ انضمام: پش نوٹیفیکیشنز، ایکسٹرنل لنک پارسنگ، آر ایس ایس فیڈ۔
مختلف سوالات کے ساتھ ساتھیوں کی مدد کرنا، جن کے جوابات کے لیے نامعلوم کوڈ میں غوطہ لگانے کی ضرورت ہے۔

اس وقت کے دوران، سائٹ کے بہت سے اجزاء میں میرا ہاتھ تھا۔ میں اس تجربے کو شیئر کرنا چاہتا ہوں۔

عمومی فن تعمیر

ہر چیز، ہمیشہ کی طرح، سرور یا سرورز کے گروپ سے شروع ہوتی ہے جو درخواستیں قبول کرتے ہیں۔

فرنٹ سرور

فرنٹ سرور HTTPS، RTMP اور WSS کے ذریعے درخواستیں قبول کرتا ہے۔

HTTPS - یہ سائٹ کے مرکزی اور موبائل ویب ورژن کے لیے درخواستیں ہیں: vk.com اور m.vk.com، اور ہمارے API کے دیگر سرکاری اور غیر سرکاری کلائنٹس: موبائل کلائنٹس، میسنجر۔ ہمارے پاس استقبالیہ ہے۔ RTMP- علیحدہ فرنٹ سرورز کے ساتھ براہ راست نشریات کے لیے ٹریفک اور WSS- اسٹریمنگ API کے لیے کنکشن۔

سرورز پر HTTPS اور WSS کے لیے یہ قابل قدر ہے۔ نگنکس. RTMP نشریات کے لیے، ہم نے حال ہی میں اپنے حل پر سوئچ کیا ہے۔ kiveلیکن یہ رپورٹ کے دائرہ کار سے باہر ہے۔ غلطی کو برداشت کرنے کے لیے، یہ سرور عام IP پتوں کی تشہیر کرتے ہیں اور گروپس میں کام کرتے ہیں تاکہ اگر کسی سرور پر کوئی مسئلہ ہو تو صارف کی درخواستیں ضائع نہ ہوں۔ HTTPS اور WSS کے لیے، یہ وہی سرورز ٹریفک کو خفیہ کرتے ہیں تاکہ CPU بوجھ کا حصہ خود پر لے سکیں۔

ہم WSS اور RTMP کے بارے میں مزید بات نہیں کریں گے، لیکن صرف معیاری HTTPS درخواستوں کے بارے میں، جو عام طور پر ویب پروجیکٹ سے وابستہ ہوتی ہیں۔

پسدید

سامنے کے پیچھے عام طور پر بیک اینڈ سرورز ہوتے ہیں۔ وہ ان درخواستوں پر کارروائی کرتے ہیں جو فرنٹ سرور کلائنٹس سے وصول کرتے ہیں۔

یہ کے پی ایچ پی سرورز، جس پر HTTP ڈیمون چل رہا ہے، کیونکہ HTTPS پہلے سے ہی ڈکرپٹ ہے۔ kPHP ایک سرور ہے جو چلتا ہے۔ prefork ماڈل: ایک ماسٹر پراسیس شروع کرتا ہے، چائلڈ پروسیس کا ایک گروپ، سننے کے ساکٹ ان تک پہنچاتا ہے اور وہ ان کی درخواستوں پر کارروائی کرتے ہیں۔ اس صورت میں، صارف کی طرف سے ہر درخواست کے درمیان عمل کو دوبارہ شروع نہیں کیا جاتا ہے، لیکن صرف اپنی حالت کو دوبارہ شروع کرنے کے بجائے اصل صفر ویلیو کی حالت پر دوبارہ ترتیب دیا جاتا ہے۔

لوڈ کی تقسیم

ہمارے تمام بیک اینڈ مشینوں کا ایک بہت بڑا پول نہیں ہیں جو کسی بھی درخواست پر کارروائی کر سکے۔ ہم انہیں الگ الگ گروپوں میں تقسیم: جنرل، موبائل، اے پی آئی، ویڈیو، سٹیجنگ... مشینوں کے الگ گروپ کا مسئلہ باقی سب کو متاثر نہیں کرے گا۔ ویڈیو میں مسائل کی صورت میں میوزک سننے والے صارف کو مسائل کا علم بھی نہیں ہوگا۔ کس بیک اینڈ کو درخواست بھیجنی ہے اس کا فیصلہ کنفیگریشن کے مطابق فرنٹ پر موجود nginx کرتا ہے۔

میٹرک مجموعہ اور دوبارہ توازن

یہ سمجھنے کے لیے کہ ہمیں ہر گروپ میں کتنی کاریں ہونی چاہئیں، ہم QPS پر بھروسہ نہ کریں۔. بیک اینڈ مختلف ہیں، ان کی مختلف درخواستیں ہیں، ہر درخواست میں QPS کا حساب لگانے کی مختلف پیچیدگی ہے۔ اسی لیے ہم ہم مجموعی طور پر سرور پر بوجھ کے تصور کے ساتھ کام کرتے ہیں - CPU اور perf پر.

ہمارے پاس ایسے ہزاروں سرور ہیں۔ ہر فزیکل سرور تمام کور کو ری سائیکل کرنے کے لیے ایک kPHP گروپ چلاتا ہے (کیونکہ kPHP سنگل تھریڈڈ ہے)۔

مواد سرور

CS یا Content Server ایک اسٹوریج ہے۔. CS ایک ایسا سرور ہے جو فائلوں کو اسٹور کرتا ہے اور اپ لوڈ کردہ فائلوں اور تمام قسم کے بیک گراؤنڈ سنکرونس کاموں پر بھی کارروائی کرتا ہے جو مرکزی ویب فرنٹ اینڈ اسے تفویض کرتا ہے۔

ہمارے پاس دسیوں ہزار فزیکل سرورز ہیں جو فائلوں کو اسٹور کرتے ہیں۔ صارفین فائلیں اپ لوڈ کرنا پسند کرتے ہیں، اور ہم انہیں اسٹور اور شیئر کرنا پسند کرتے ہیں۔ ان میں سے کچھ سرور خصوصی pu/pp سرورز کے ذریعہ بند ہیں۔

pu/pp

اگر آپ نے VK میں نیٹ ورک ٹیب کھولا تو آپ نے pu/pp دیکھا۔

pu/pp کیا ہے؟ اگر ہم ایک کے بعد دوسرے سرور کو بند کرتے ہیں، تو بند ہونے والے سرور پر فائل اپ لوڈ اور ڈاؤن لوڈ کرنے کے دو آپشن ہیں: براہ راست کے ذریعے http://cs100500.userapi.com/path یا انٹرمیڈیٹ سرور کے ذریعے - http://pu.vk.com/c100500/path.

Pu تصویر اپ لوڈ کا تاریخی نام ہے، اور pp فوٹو پراکسی ہے۔. یعنی ایک سرور فوٹو اپ لوڈ کرنے کے لیے ہے اور دوسرا اپ لوڈ کرنے کے لیے۔ اب نہ صرف تصاویر لوڈ کی جاتی ہیں بلکہ نام بھی محفوظ کر لیا گیا ہے۔

یہ سرورز HTTPS سیشن ختم کریں۔سٹوریج سے پروسیسر کا بوجھ ہٹانے کے لیے۔ نیز، چونکہ ان سرورز پر صارف کی فائلوں پر کارروائی کی جاتی ہے، اس لیے ان مشینوں پر جتنی کم حساس معلومات محفوظ کی جائیں گی، اتنا ہی بہتر ہے۔ مثال کے طور پر، HTTPS انکرپشن کیز۔

چونکہ مشینیں ہماری دوسری مشینوں کے ذریعے بند ہوتی ہیں، اس لیے ہم انہیں "سفید" بیرونی IPs نہ دینے کے متحمل ہو سکتے ہیں، اور "گرے" دیں. اس طرح ہم نے آئی پی پول پر بچت کی اور مشینوں کو باہر کی رسائی سے بچانے کی ضمانت دی - اس میں داخل ہونے کے لیے کوئی آئی پی نہیں ہے۔

مشترکہ IPs پر لچک. غلطی کو برداشت کرنے کے معاملے میں، اسکیم ایک ہی طرح سے کام کرتی ہے - کئی فزیکل سرورز کا ایک مشترکہ فزیکل IP ہوتا ہے، اور ان کے سامنے موجود ہارڈویئر انتخاب کرتا ہے کہ درخواست کہاں بھیجنی ہے۔ میں دوسرے اختیارات کے بارے میں بعد میں بات کروں گا۔

متنازعہ نکتہ یہ ہے کہ اس معاملے میں کلائنٹ کم کنکشن رکھتا ہے. اگر کئی مشینوں کے لیے ایک ہی IP ہے - ایک ہی میزبان کے ساتھ: pu.vk.com یا pp.vk.com، کلائنٹ براؤزر کے پاس ایک میزبان کو بیک وقت درخواستوں کی تعداد کی حد ہوتی ہے۔ لیکن ہر جگہ HTTP/2 کے زمانے میں، مجھے یقین ہے کہ یہ اب اتنا متعلقہ نہیں ہے۔

اسکیم کا واضح نقصان یہ ہے کہ اسے کرنا پڑتا ہے۔ تمام ٹریفک کو پمپ کریں۔، جو دوسرے سرور کے ذریعے اسٹوریج میں جاتا ہے۔ چونکہ ہم مشینوں کے ذریعے ٹریفک پمپ کرتے ہیں، اس لیے ہم ابھی تک بھاری ٹریفک کو پمپ نہیں کر سکتے، مثال کے طور پر، ویڈیو، اسی سکیم کا استعمال کرتے ہوئے۔ ہم اسے براہ راست منتقل کرتے ہیں - خاص طور پر ویڈیو کے لیے علیحدہ اسٹوریج کے لیے ایک علیحدہ براہ راست کنکشن۔ ہم ہلکے مواد کو پراکسی کے ذریعے منتقل کرتے ہیں۔

کچھ عرصہ قبل ہمیں پراکسی کا ایک بہتر ورژن ملا۔ اب میں آپ کو بتاتا ہوں کہ وہ عام لوگوں سے کیسے مختلف ہیں اور یہ کیوں ضروری ہے۔

اتوار

ستمبر 2017 میں، اوریکل، جس نے پہلے سن کو خریدا تھا، سورج ملازمین کی ایک بڑی تعداد کو برطرف. ہم کہہ سکتے ہیں کہ اس وقت کمپنی کا وجود ختم ہو گیا ہے۔ نئے نظام کے لیے نام کا انتخاب کرتے وقت، ہمارے منتظمین نے اس کمپنی کی یاد کو خراج تحسین پیش کرنے کا فیصلہ کیا اور نئے نظام کا نام سن رکھا۔ اپنے درمیان ہم اسے صرف "سورج" کہتے ہیں۔

پی پی کو کچھ مسائل تھے۔ فی گروپ ایک IP - غیر موثر کیش. کئی فزیکل سرورز ایک مشترکہ IP ایڈریس کا اشتراک کرتے ہیں، اور یہ کنٹرول کرنے کا کوئی طریقہ نہیں ہے کہ درخواست کس سرور پر جائے گی۔ لہذا، اگر مختلف صارف ایک ہی فائل کے لیے آتے ہیں، تو اگر ان سرورز پر کوئی کیش ہو تو فائل ہر سرور کے کیش میں ختم ہو جاتی ہے۔ یہ انتہائی ناکارہ سکیم ہے، لیکن کچھ نہیں ہو سکا۔

نتیجتاً- ہم مواد کو تیز نہیں کر سکتےکیونکہ ہم اس گروپ کے لیے مخصوص سرور کا انتخاب نہیں کر سکتے ہیں - ان کا ایک مشترکہ IP ہے۔ اس کے علاوہ کچھ اندرونی وجوہات کی بناء پر ہمارے پاس علاقوں میں اس طرح کے سرورز کو انسٹال کرنا ممکن نہیں تھا۔. وہ صرف سینٹ پیٹرزبرگ میں کھڑے تھے۔

سورج کے ساتھ، ہم نے انتخاب کے نظام کو تبدیل کیا. اب ہمارے پاس ہے۔ anycast روٹنگ: متحرک روٹنگ، کوئی کاسٹ، سیلف چیک ڈیمون۔ ہر سرور کا اپنا انفرادی IP ہوتا ہے، لیکن ایک مشترکہ سب نیٹ۔ ہر چیز کو اس طرح ترتیب دیا گیا ہے کہ اگر ایک سرور فیل ہو جائے تو ٹریفک خود بخود اسی گروپ کے دوسرے سرورز پر پھیل جاتی ہے۔ اب ایک مخصوص سرور کو منتخب کرنا ممکن ہے، کوئی فالتو کیشنگ نہیں۔، اور وشوسنییتا متاثر نہیں ہوا تھا۔

وزن کی حمایت. اب ہم ضرورت کے مطابق مختلف طاقتوں کی مشینیں لگانے کے متحمل ہوسکتے ہیں، اور ساتھ ہی، عارضی مسائل کی صورت میں، کام کرنے والے "سورج" کے وزن کو تبدیل کرکے ان پر بوجھ کم کریں، تاکہ وہ "آرام" کریں اور دوبارہ کام شروع کریں۔

مواد کی شناخت کے لحاظ سے شیئرنگ. شارڈنگ کے بارے میں ایک مضحکہ خیز بات: ہم عام طور پر مواد کو شارٹ کرتے ہیں تاکہ مختلف صارفین ایک ہی "سورج" کے ذریعے ایک ہی فائل پر جائیں تاکہ ان کے پاس مشترکہ کیش ہو۔

ہم نے حال ہی میں "Clover" ایپلیکیشن لانچ کی ہے۔ یہ براہ راست نشریات میں ایک آن لائن کوئز ہے، جہاں میزبان سوالات پوچھتا ہے اور صارفین آپشنز کا انتخاب کرتے ہوئے حقیقی وقت میں جواب دیتے ہیں۔ ایپ میں ایک چیٹ ہے جہاں صارف چیٹ کر سکتے ہیں۔ بیک وقت براڈکاسٹ سے منسلک ہو سکتے ہیں۔ 100 ہزار سے زیادہ لوگ. وہ سبھی پیغامات لکھتے ہیں جو تمام شرکاء کو بھیجے جاتے ہیں، اور پیغام کے ساتھ ایک اوتار آتا ہے۔ اگر ایک "سورج" میں 100 ہزار لوگ ایک اوتار کے لیے آتے ہیں، تو یہ کبھی کبھی بادل کے پیچھے بھی گھوم سکتا ہے۔

ایک ہی فائل کے لیے درخواستوں کے پھٹ جانے کو برداشت کرنے کے لیے، یہ ایک خاص قسم کے مواد کے لیے ہے جسے ہم ایک احمقانہ اسکیم آن کرتے ہیں جو فائلوں کو خطے میں موجود تمام "سورج" میں پھیلا دیتی ہے۔

اندر سے سورج

nginx پر ریورس پراکسی، یا تو RAM میں یا تیز Optane/NVMe ڈسکوں پر کیش۔ مثال: http://sun4-2.userapi.com/c100500/path - "سورج" کا ایک لنک، جو چوتھے علاقے میں واقع ہے، دوسرا سرور گروپ۔ یہ پاتھ فائل کو بند کر دیتا ہے، جو جسمانی طور پر سرور 100500 پر موجود ہے۔

کیشے

ہم اپنی آرکیٹیکچرل اسکیم میں ایک اور نوڈ شامل کرتے ہیں - کیشنگ ماحول۔

ذیل میں ترتیب کا خاکہ ہے۔ علاقائی کیشان میں سے تقریباً 20 ہیں۔ یہ وہ جگہیں ہیں جہاں کیش اور "سورج" واقع ہیں، جو ٹریفک کو اپنے ذریعے کیش کر سکتے ہیں۔

یہ ملٹی میڈیا مواد کی کیشنگ ہے؛ یہاں صارف کا کوئی ڈیٹا محفوظ نہیں ہے - صرف موسیقی، ویڈیو، تصاویر۔

صارف کے علاقے کا تعین کرنے کے لیے، ہم ہم علاقوں میں اعلان کردہ BGP نیٹ ورک کے سابقے جمع کرتے ہیں۔. فال بیک کی صورت میں، ہمیں geoip ڈیٹا بیس کو بھی پارس کرنا پڑتا ہے اگر ہم سابقہ جات کے ذریعے IP نہیں ڈھونڈ سکے۔ ہم صارف کے IP کے ذریعہ خطے کا تعین کرتے ہیں۔. کوڈ میں، ہم صارف کے ایک یا زیادہ علاقوں کو دیکھ سکتے ہیں - وہ پوائنٹس جن کے وہ جغرافیائی طور پر سب سے قریب ہے۔

یہ کس طرح کام کرتا ہے؟

ہم خطے کے لحاظ سے فائلوں کی مقبولیت کو شمار کرتے ہیں۔. وہاں بہت سے علاقائی کیشے ہیں جہاں صارف واقع ہے، اور ایک فائل شناخت کنندہ - ہم اس جوڑے کو لیتے ہیں اور ہر ڈاؤن لوڈ کے ساتھ درجہ بندی میں اضافہ کرتے ہیں۔

ایک ہی وقت میں، شیاطین - خطوں میں خدمات - وقتاً فوقتاً API پر آتے ہیں اور کہتے ہیں: "میں فلاں فلاں کیش ہوں، مجھے اپنے علاقے کی سب سے مشہور فائلوں کی فہرست دیں جو ابھی تک مجھ پر نہیں ہیں۔ " API درجہ بندی کے لحاظ سے ترتیب دی گئی فائلوں کا ایک گروپ فراہم کرتا ہے، ڈیمون انہیں ڈاؤن لوڈ کرتا ہے، انہیں علاقوں میں لے جاتا ہے اور وہاں سے فائلیں فراہم کرتا ہے۔ یہ کیش سے pu/pp اور Sun کے درمیان بنیادی فرق ہے: وہ فائل کو فوری طور پر اپنے ذریعے دیتے ہیں، چاہے یہ فائل کیشے میں نہ ہو، اور کیش پہلے فائل کو اپنے پاس ڈاؤن لوڈ کرتا ہے، اور پھر اسے واپس دینا شروع کر دیتا ہے۔

اس صورت میں ہم حاصل کرتے ہیں صارفین کے قریب مواد اور نیٹ ورک کا بوجھ پھیلانا۔ مثال کے طور پر، ہم صرف ماسکو کیش سے 1 Tbit/s سے زیادہ اوقات کے دوران تقسیم کرتے ہیں۔

لیکن مسائل ہیں - کیشے سرور ربڑ نہیں ہیں۔. انتہائی مقبول مواد کے لیے، بعض اوقات علیحدہ سرور کے لیے کافی نیٹ ورک نہیں ہوتا ہے۔ ہمارے کیشے سرورز 40-50 Gbit/s ہیں، لیکن ایسا مواد ہے جو اس طرح کے چینل کو مکمل طور پر بند کر دیتا ہے۔ ہم خطے میں مقبول فائلوں کی ایک سے زیادہ کاپیوں کے اسٹوریج کو لاگو کرنے کی طرف بڑھ رہے ہیں۔ مجھے امید ہے کہ ہم اسے سال کے آخر تک نافذ کر دیں گے۔

ہم نے عمومی فن تعمیر کو دیکھا۔

فرنٹ سرورز جو درخواستیں قبول کرتے ہیں۔
بیک اینڈز جو کہ پروسیسنگ کی درخواستیں کرتا ہے۔
سٹوریج جو دو قسم کے پراکسیز سے بند ہیں۔
علاقائی کیشز۔

اس خاکہ سے کیا غائب ہے؟ یقینا، وہ ڈیٹا بیس جس میں ہم ڈیٹا کو محفوظ کرتے ہیں۔

ڈیٹا بیس یا انجن

ہم انہیں ڈیٹا بیس نہیں بلکہ انجن کہتے ہیں - انجن، کیونکہ ہمارے پاس عملی طور پر عام طور پر قبول شدہ معنوں میں ڈیٹا بیس نہیں ہیں۔

یہ ایک ضروری اقدام ہے۔. ایسا اس لیے ہوا کیونکہ 2008-2009 میں، جب VK کی مقبولیت میں دھماکہ خیز اضافہ ہوا، اس پروجیکٹ نے مکمل طور پر MySQL اور Memcache پر کام کیا اور اس میں مسائل تھے۔ MySQL فائلوں کو کریش اور کرپٹ کرنا پسند کرتا تھا، جس کے بعد یہ ٹھیک نہیں ہوتا تھا، اور Memcache کی کارکردگی میں بتدریج کمی آتی گئی اور اسے دوبارہ شروع کرنا پڑا۔

یہ پتہ چلتا ہے کہ تیزی سے مقبول پروجیکٹ میں مستقل اسٹوریج تھا، جو ڈیٹا کو خراب کرتا ہے، اور ایک کیش، جو سست ہوجاتا ہے. ایسے حالات میں بڑھتے ہوئے منصوبے کو تیار کرنا مشکل ہے۔ فیصلہ کیا گیا کہ ان اہم چیزوں کو دوبارہ لکھنے کی کوشش کی جائے جن پر پروجیکٹ ہماری اپنی سائیکلوں پر مرکوز تھا۔

حل کامیاب رہا۔. ایسا کرنے کا موقع بھی تھا، ساتھ ہی ایک انتہائی ضرورت بھی، کیونکہ اس وقت اسکیلنگ کے دوسرے طریقے موجود نہیں تھے۔ ڈیٹا بیس کا ایک گروپ نہیں تھا، NoSQL ابھی موجود نہیں تھا، صرف MySQL، Memcache، PostrgreSQL تھے - اور بس۔

یونیورسل آپریشن. ترقی کی قیادت ہماری C ڈویلپرز کی ٹیم نے کی اور سب کچھ مستقل مزاجی سے کیا گیا۔ انجن سے قطع نظر، ان سب کے پاس تقریباً ایک ہی فائل فارمیٹ تھا جو ڈسک پر لکھا گیا تھا، ایک جیسے لانچ پیرامیٹرز، ایک ہی طریقے سے پروسیس شدہ سگنلز تھے، اور کنارے کے حالات اور مسائل کی صورت میں تقریباً یکساں برتاؤ کرتے تھے۔ انجنوں کی نشوونما کے ساتھ، منتظمین کے لیے سسٹم کو چلانا آسان ہو جاتا ہے - کوئی چڑیا گھر نہیں ہے جس کو برقرار رکھنے کی ضرورت ہے، اور انہیں ہر نئے تھرڈ پارٹی ڈیٹا بیس کو چلانے کا طریقہ دوبارہ سیکھنا پڑتا ہے، جس کی وجہ سے تیزی اور آسانی سے اضافہ ممکن ہوا۔ ان کی تعداد.

انجنوں کی اقسام

ٹیم نے بہت سے انجن لکھے۔ ان میں سے صرف کچھ یہ ہیں: دوست، اشارے، تصویر، ipdb، خطوط، فہرستیں، لاگز، memcached، meowdb، خبریں، nostradamus، تصویر، پلے لسٹس، pmemcached، سینڈ باکس، تلاش، اسٹوریج، پسند، کام، …

ہر کام کے لیے جس کے لیے مخصوص ڈیٹا ڈھانچہ کی ضرورت ہوتی ہے یا غیر معمولی درخواستوں پر کارروائی کرتی ہے، سی ٹیم ایک نیا انجن لکھتی ہے۔ کیوں نہیں.

ہمارے پاس الگ انجن ہے۔ memcached، جو کہ ایک عام سے ملتا جلتا ہے، لیکن بہت سی چیزوں کے ساتھ، اور جو سست نہیں ہوتا ہے۔ کلک ہاؤس نہیں، لیکن یہ بھی کام کرتا ہے۔ الگ سے دستیاب ہے۔ pmemcached ہے - مسلسل memcached، جو کہ RAM میں فٹ ہونے کے بجائے ڈسک پر ڈیٹا کو بھی ذخیرہ کر سکتا ہے، تاکہ دوبارہ شروع کرنے پر ڈیٹا ضائع نہ ہو۔ انفرادی کاموں کے لیے مختلف انجن ہیں: قطاریں، فہرستیں، سیٹس - ہر وہ چیز جو ہمارے پروجیکٹ کو درکار ہے۔

کلسٹرز

کوڈ کے نقطہ نظر سے، انجن یا ڈیٹا بیس کو عمل، اداروں، یا مثال کے طور پر سوچنے کی ضرورت نہیں ہے۔ کوڈ خاص طور پر انجنوں کے گروپوں کے ساتھ کلسٹرز کے ساتھ کام کرتا ہے۔ ایک قسم فی کلسٹر. ہم کہتے ہیں کہ ایک میمکیچڈ کلسٹر ہے - یہ صرف مشینوں کا ایک گروپ ہے۔

کوڈ کو جسمانی مقام، سائز، یا سرورز کی تعداد بالکل بھی جاننے کی ضرورت نہیں ہے۔ وہ ایک مخصوص شناخت کنندہ کا استعمال کرتے ہوئے کلسٹر میں جاتا ہے۔

اس کے کام کرنے کے لیے، آپ کو ایک اور ہستی شامل کرنے کی ضرورت ہے جو کوڈ اور انجنوں کے درمیان واقع ہے۔ پراکسی.

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 اسکیما اختیاری فیلڈز، پیچیدہ اقسام - بلٹ ان اسکیلرز کی توسیعات، اور سوالات کی پیشگی وضاحت کرتی ہے۔ سب کچھ اس پروٹوکول کے مطابق کام کرتا ہے۔

TCP/UDP پر TL پر RPC… UDP؟

ہمارے پاس انجن کی درخواستوں کو انجام دینے کے لیے ایک RPC پروٹوکول ہے جو TL اسکیم کے اوپر چلتا ہے۔ یہ سب TCP/UDP کنکشن پر کام کرتا ہے۔ TCP سمجھ میں آتا ہے، لیکن ہمیں UDP کی اکثر ضرورت کیوں ہوتی ہے؟

UDP مدد کرتا ہے۔ سرورز کے درمیان کنکشن کی ایک بڑی تعداد کے مسئلے سے بچیں۔. اگر ہر سرور کے پاس ایک RPC پراکسی ہے اور، عام طور پر، یہ کسی بھی انجن میں جا سکتا ہے، تو فی سرور دسیوں ہزار TCP کنکشنز ہیں۔ ایک بوجھ ہے، لیکن یہ بیکار ہے. UDP کے معاملے میں یہ مسئلہ موجود نہیں ہے۔

کوئی فالتو TCP ہینڈ شیک نہیں۔. یہ ایک عام مسئلہ ہے: جب ایک نیا انجن یا نیا سرور لانچ کیا جاتا ہے، تو بہت سے TCP کنکشن ایک ساتھ قائم ہو جاتے ہیں۔ چھوٹی ہلکی پھلکی درخواستوں کے لیے، مثال کے طور پر، UDP پے لوڈ، کوڈ اور انجن کے درمیان تمام مواصلت ہوتی ہے۔ دو UDP پیکٹ: ایک ایک سمت میں اڑتا ہے، دوسرا دوسری طرف۔ ایک راؤنڈ ٹرپ - اور کوڈ کو انجن سے بغیر مصافحہ کے جواب موصول ہوا۔

جی ہاں، یہ سب صرف کام کرتا ہے پیکٹ کے نقصان کے بہت کم فیصد کے ساتھ. پروٹوکول میں ری ٹرانسمٹس اور ٹائم آؤٹ کے لیے سپورٹ ہے، لیکن اگر ہم بہت کچھ کھو دیتے ہیں، تو ہمیں تقریباً TCP مل جائے گا، جو کہ فائدہ مند نہیں ہے۔ ہم UDP کو سمندروں میں نہیں چلاتے ہیں۔

ہمارے پاس ایسے ہزاروں سرورز ہیں، اور اسکیم ایک ہی ہے: ہر ایک فزیکل سرور پر انجنوں کا ایک پیکٹ انسٹال ہوتا ہے۔ وہ زیادہ تر سنگل تھریڈڈ ہوتے ہیں تاکہ بلاک کیے بغیر جلد سے جلد چل سکیں، اور سنگل تھریڈڈ حل کے طور پر شارڈ کیے جاتے ہیں۔ ایک ہی وقت میں، ہمارے پاس ان انجنوں سے زیادہ قابل اعتماد کوئی چیز نہیں ہے، اور مسلسل ڈیٹا اسٹوریج پر بہت زیادہ توجہ دی جاتی ہے۔

مستقل ڈیٹا اسٹوریج

انجن binlogs لکھتے ہیں۔. بِن لاگ ایک فائل ہے جس کے آخر میں اسٹیٹ یا ڈیٹا میں تبدیلی کا واقعہ شامل کیا جاتا ہے۔ مختلف حلوں میں اسے مختلف طریقے سے کہا جاتا ہے: بائنری لاگ، WAL, اے او ایفلیکن اصول ایک ہی ہے۔

انجن کو دوبارہ شروع کرنے پر کئی سالوں تک پورے بن لاگ کو دوبارہ پڑھنے سے روکنے کے لیے، انجن لکھتے ہیں۔ سنیپ شاٹس - موجودہ حالت. اگر ضروری ہو تو، وہ پہلے اس سے پڑھیں، اور پھر بن لاگ سے پڑھنا ختم کریں۔ تمام binlogs ایک ہی بائنری فارمیٹ میں لکھے گئے ہیں - TL سکیم کے مطابق، تاکہ منتظمین اپنے ٹولز کا استعمال کرتے ہوئے ان کا یکساں طور پر انتظام کر سکیں۔ سنیپ شاٹس کی ایسی کوئی ضرورت نہیں ہے۔ ایک عام ہیڈر ہے جو بتاتا ہے کہ کس کا سنیپ شاٹ int ہے، انجن کا جادو ہے، اور کون سا باڈی کسی کے لیے اہم نہیں ہے۔ یہ اسنیپ شاٹ ریکارڈ کرنے والے انجن کے ساتھ ایک مسئلہ ہے۔

میں تیزی سے آپریشن کے اصول کو بیان کروں گا۔ ایک سرور ہے جس پر انجن چلتا ہے۔ وہ لکھنے کے لیے ایک نیا خالی بن لاگ کھولتا ہے اور اس میں تبدیلی کے لیے ایک واقعہ لکھتا ہے۔

کسی وقت، وہ یا تو خود سنیپ شاٹ لینے کا فیصلہ کرتا ہے، یا اسے سگنل ملتا ہے۔ سرور ایک نئی فائل بناتا ہے، اس میں اپنی پوری حالت لکھتا ہے، موجودہ binlog سائز - آفسیٹ - کو فائل کے آخر میں جوڑتا ہے، اور مزید لکھنا جاری رکھتا ہے۔ نیا binlog نہیں بنایا گیا ہے۔

کسی وقت، جب انجن دوبارہ شروع ہوتا ہے، تو ڈسک پر ایک بن لاگ اور اسنیپ شاٹ دونوں ہوں گے۔ انجن پورے سنیپ شاٹ کو پڑھتا ہے اور ایک خاص مقام پر اپنی حالت کو بڑھاتا ہے۔

وہ پوزیشن پڑھتا ہے جو سنیپ شاٹ بنانے کے وقت تھی اور بن لاگ کا سائز۔

موجودہ حالت جاننے کے لیے binlog کا اختتام پڑھتا ہے اور مزید واقعات لکھتا رہتا ہے۔ یہ ایک سادہ سکیم ہے؛ ہمارے تمام انجن اس کے مطابق کام کرتے ہیں۔

ڈیٹا کی نقل

نتیجے کے طور پر، ہمارے میں ڈیٹا کی نقل بیان پر مبنی - ہم binlog میں صفحہ میں کوئی تبدیلی نہیں کرتے بلکہ لکھتے ہیں۔ درخواستوں کو تبدیل کریں. نیٹ ورک پر آنے والی چیزوں سے بہت ملتا جلتا ہے، صرف تھوڑا سا ترمیم شدہ۔

اسی اسکیم کو نہ صرف نقل کے لیے استعمال کیا جاتا ہے بلکہ بیک اپ بنانے کے لیے. ہمارے پاس ایک انجن ہے - ایک رائٹنگ ماسٹر جو بن لاگ کو لکھتا ہے۔ کسی بھی دوسری جگہ جہاں منتظمین نے اسے ترتیب دیا ہے، یہ binlog کاپی کیا جاتا ہے، اور بس - ہمارے پاس بیک اپ ہے۔

اگر ضرورت ہو تو نقل پڑھناCPU پڑھنے کے بوجھ کو کم کرنے کے لیے، ریڈنگ انجن کو آسانی سے لانچ کیا جاتا ہے، جو بِن لاگ کے آخر کو پڑھتا ہے اور ان کمانڈز کو مقامی طور پر چلاتا ہے۔

یہاں وقفہ بہت چھوٹا ہے، اور یہ معلوم کرنا ممکن ہے کہ نقل ماسٹر سے کتنا پیچھے ہے۔

RPC پراکسی میں ڈیٹا شارڈنگ

شارڈنگ کیسے کام کرتی ہے؟ پراکسی کس طرح سمجھتی ہے کہ کس کلسٹر شارڈ کو بھیجنا ہے؟ کوڈ یہ نہیں کہتا: "15 شارڈز کے لیے بھیجیں!" - نہیں، یہ پراکسی نے کیا ہے۔

سب سے آسان اسکیم فرسٹنٹ ہے۔ - درخواست میں پہلا نمبر۔

get(photo100_500) => 100 % N.

یہ ایک سادہ میم کیچڈ ٹیکسٹ پروٹوکول کے لیے ایک مثال ہے، لیکن یقیناً سوالات پیچیدہ اور ساختی ہو سکتے ہیں۔ مثال سوال میں پہلا نمبر لیتی ہے اور بقیہ جب کلسٹر سائز سے تقسیم کیا جاتا ہے۔

یہ تب مفید ہے جب ہم کسی ایک ہستی کا ڈیٹا لوکلٹی رکھنا چاہتے ہیں۔ آئیے کہتے ہیں کہ 100 ایک صارف یا گروپ آئی ڈی ہے، اور ہم چاہتے ہیں کہ ایک ہستی کا تمام ڈیٹا پیچیدہ سوالات کے لیے ایک شارڈ پر ہو۔

اگر ہمیں پرواہ نہیں ہے کہ درخواستیں کس طرح کلسٹر میں پھیلی ہوئی ہیں، تو ایک اور آپشن ہے - پورے شارڈ کو ہیش کرنا.

hash(photo100_500) => 3539886280 % N

ہمیں ہیش، تقسیم کا بقیہ حصہ اور شارڈ نمبر بھی ملتا ہے۔

یہ دونوں آپشن صرف اس صورت میں کام کرتے ہیں جب ہم اس حقیقت کے لیے تیار ہوں کہ جب ہم کلسٹر کا سائز بڑھاتے ہیں، تو ہم اسے تقسیم کر دیتے ہیں یا اسے کئی گنا بڑھا دیتے ہیں۔ مثال کے طور پر، ہمارے پاس 16 شارڈز تھے، ہمارے پاس کافی نہیں ہے، ہم مزید چاہتے ہیں - ہم بغیر ٹائم ٹائم کے محفوظ طریقے سے 32 حاصل کر سکتے ہیں۔ اگر ہم ضربوں کو نہیں بڑھانا چاہتے ہیں، تو اس کا وقت بند ہو جائے گا، کیونکہ ہم نقصان کے بغیر ہر چیز کو درست طریقے سے تقسیم نہیں کر پائیں گے۔ یہ اختیارات مفید ہیں، لیکن ہمیشہ نہیں۔

اگر ہمیں سرورز کی من مانی تعداد کو شامل کرنے یا ہٹانے کی ضرورت ہو تو ہم استعمال کرتے ہیں۔ انگوٹی a la Ketama پر مسلسل ہیشنگ. لیکن ایک ہی وقت میں، ہم ڈیٹا کی لوکلٹی کو مکمل طور پر کھو دیتے ہیں؛ ہمیں درخواست کو کلسٹر میں ضم کرنا ہوگا تاکہ ہر ٹکڑا اپنا چھوٹا جواب واپس کرے، اور پھر جوابات کو پراکسی میں ضم کر دیں۔

انتہائی مخصوص درخواستیں ہیں۔ یہ اس طرح لگتا ہے: RPC پراکسی درخواست وصول کرتی ہے، اس بات کا تعین کرتی ہے کہ کس کلسٹر میں جانا ہے اور شارڈ کا تعین کرتا ہے۔ پھر یا تو تحریری ماسٹرز ہیں، یا، اگر کلسٹر میں ریپلیکا سپورٹ ہے، تو یہ ڈیمانڈ پر ایک ریپلیکا کو بھیجتا ہے۔ پراکسی یہ سب کرتی ہے۔

نوشتہ جات

ہم کئی طریقوں سے لاگ لکھتے ہیں۔ سب سے واضح اور سادہ ہے۔ memcache پر لاگ لکھیں۔.

ring-buffer: prefix.idx = line

ایک کلیدی سابقہ ہے - لاگ کا نام، ایک لائن، اور اس لاگ کا سائز ہے - لائنوں کی تعداد۔ ہم 0 سے لائنوں کی تعداد مائنس 1 تک ایک بے ترتیب نمبر لیتے ہیں۔ memcache میں کلید ایک سابقہ ہے جو اس بے ترتیب نمبر کے ساتھ جڑا ہوا ہے۔ ہم لاگ لائن اور موجودہ وقت کو قدر میں محفوظ کرتے ہیں۔

جب نوشتہ جات کو پڑھنا ضروری ہوتا ہے تو ہم اس پر عمل کرتے ہیں۔ ملٹی گیٹ تمام چابیاں، وقت کے لحاظ سے ترتیب دی گئیں، اور اس طرح حقیقی وقت میں پروڈکشن لاگ حاصل کریں۔ اس اسکیم کا استعمال اس وقت کیا جاتا ہے جب آپ کو حقیقی وقت میں پروڈکشن میں کسی چیز کو ڈیبگ کرنے کی ضرورت ہوتی ہے، بغیر کسی چیز کو توڑے، بغیر روکے یا دوسری مشینوں کو ٹریفک کی اجازت دیے، لیکن یہ لاگ زیادہ دیر تک نہیں چلتا ہے۔

لاگز کے قابل اعتماد اسٹوریج کے لیے ہمارے پاس ایک انجن ہے۔ لاگ انجن. یہی وجہ ہے کہ اسے بنایا گیا تھا اور بڑے پیمانے پر کلسٹرز کی ایک بڑی تعداد میں استعمال ہوتا ہے۔ سب سے بڑا کلسٹر جس کے بارے میں میں جانتا ہوں کہ 600 TB پیکڈ لاگز اسٹور کرتا ہے۔

انجن بہت پرانا ہے، کلسٹرز ہیں جو پہلے ہی 6-7 سال پرانے ہیں۔ اس کے ساتھ کچھ مسائل ہیں جنہیں ہم حل کرنے کی کوشش کر رہے ہیں، مثال کے طور پر، ہم نے لاگز کو ذخیرہ کرنے کے لیے ClickHouse کو فعال طور پر استعمال کرنا شروع کیا۔

کلک ہاؤس میں لاگز جمع کرنا

یہ خاکہ دکھاتا ہے کہ ہم اپنے انجنوں میں کیسے چلتے ہیں۔

ایسا کوڈ ہے جو مقامی طور پر RPC کے ذریعے RPC-proxy تک جاتا ہے، اور یہ سمجھتا ہے کہ انجن کو کہاں جانا ہے۔ اگر ہم کلک ہاؤس میں لاگ لکھنا چاہتے ہیں، تو ہمیں اس اسکیم میں دو حصوں کو تبدیل کرنے کی ضرورت ہے:

کلک ہاؤس کے ساتھ کچھ انجن کو تبدیل کریں؛
RPC پراکسی کو تبدیل کریں، جو ClickHouse تک رسائی حاصل نہیں کر سکتی، کچھ حل کے ساتھ، اور RPC کے ذریعے۔

انجن آسان ہے - ہم اسے سرور یا کلک ہاؤس والے سرورز کے کلسٹر سے بدل دیتے ہیں۔

اور کلک ہاؤس پر جانے کے لیے، ہم نے کیا۔ کیٹن ہاؤس. اگر ہم براہ راست KittenHouse سے ClickHouse جاتے ہیں، تو اس کا مقابلہ نہیں ہوگا۔ یہاں تک کہ درخواستوں کے بغیر، یہ مشینوں کی ایک بڑی تعداد کے HTTP کنکشن سے اضافہ کرتا ہے۔ اسکیم کے کام کرنے کے لیے، ClickHouse والے سرور پر مقامی ریورس پراکسی اٹھائی جاتی ہے۔، جو اس طرح لکھا گیا ہے کہ یہ کنکشن کی مطلوبہ مقدار کو برداشت کر سکتا ہے۔ یہ نسبتاً قابل اعتماد طریقے سے اپنے اندر ڈیٹا بفر بھی کر سکتا ہے۔

بعض اوقات ہم RPC اسکیم کو غیر معیاری حل میں لاگو نہیں کرنا چاہتے، مثال کے طور پر، nginx میں۔ لہذا، KittenHouse UDP کے ذریعے لاگ وصول کرنے کی صلاحیت رکھتا ہے۔

اگر لاگس بھیجنے والا اور وصول کنندہ ایک ہی مشین پر کام کرتے ہیں، تو مقامی میزبان کے اندر UDP پیکٹ کے کھونے کا امکان کافی کم ہے۔ فریق ثالث کے حل میں RPC کو نافذ کرنے کی ضرورت کے درمیان سمجھوتے کے طور پر، ہم صرف UDP بھیجنے کا استعمال کرتے ہیں۔ ہم بعد میں اس اسکیم پر واپس جائیں گے۔

نگرانی

ہمارے پاس دو قسم کے لاگز ہیں: وہ جو ایڈمنسٹریٹرز نے اپنے سرورز پر جمع کیے ہیں اور وہ جو کوڈ سے ڈویلپرز نے لکھے ہیں۔ وہ دو قسم کے میٹرکس سے مطابقت رکھتے ہیں: نظام اور مصنوعات.

سسٹم میٹرکس

یہ ہمارے تمام سرورز پر کام کرتا ہے۔ نیٹ ڈیٹا، جو اعداد و شمار جمع کرتا ہے اور انہیں بھیجتا ہے۔ گریفائٹ کاربن. لہذا، ClickHouse کو اسٹوریج سسٹم کے طور پر استعمال کیا جاتا ہے، نہ کہ Whisper، مثال کے طور پر۔ اگر ضروری ہو تو، آپ کلک ہاؤس سے براہ راست پڑھ سکتے ہیں، یا استعمال کرسکتے ہیں۔ گرافانا میٹرکس، گرافس اور رپورٹس کے لیے۔ بطور ڈیولپر، ہمارے پاس نیٹ ڈیٹا اور گرافانا تک کافی رسائی ہے۔

پروڈکٹ میٹرکس

سہولت کے لیے ہم نے بہت سی چیزیں لکھی ہیں۔ مثال کے طور پر، عام فنکشنز کا ایک سیٹ ہے جو آپ کو شماریات میں شمار، منفرد شمار کی قدریں لکھنے کی اجازت دیتا ہے، جو کہیں آگے بھیجی جاتی ہیں۔

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

$stats = statlogsStatData($params)

اس کے بعد، ہم چھانٹنے اور گروپ بندی کے فلٹرز استعمال کر سکتے ہیں اور اعداد و شمار سے ہر وہ کام کر سکتے ہیں جو ہم چاہتے ہیں - گرافس بنائیں، واچ ڈاگس کو ترتیب دیں۔

ہم بہت لکھتے ہیں۔ بہت سے میٹرکس واقعات کی تعداد 600 بلین سے 1 ٹریلین یومیہ ہے۔ تاہم، ہم انہیں برقرار رکھنا چاہتے ہیں۔ کم از کم ایک دو سالمیٹرکس میں رجحانات کو سمجھنے کے لیے۔ یہ سب ایک ساتھ رکھنا ایک بڑا مسئلہ ہے جسے ہم نے ابھی تک حل نہیں کیا ہے۔ میں آپ کو بتاؤں گا کہ یہ پچھلے کچھ سالوں سے کیسے کام کر رہا ہے۔

ہمارے پاس ایسے افعال ہیں جو ان میٹرکس کو لکھتے ہیں۔ مقامی memcache پراندراجات کی تعداد کو کم کرنے کے لیے۔ ایک بار ایک مختصر وقت میں مقامی طور پر لانچ کیا گیا۔ stats-deemon تمام ریکارڈ جمع کرتا ہے۔ اگلا، شیطان میٹرکس کو سرور کی دو تہوں میں ضم کرتا ہے۔ لاگز جمع کرنے والے، جو ہماری مشینوں کے ایک گروپ سے اعدادوشمار کو جمع کرتا ہے تاکہ ان کے پیچھے کی پرت مر نہ جائے۔

اگر ضروری ہو تو، ہم لاگس جمع کرنے والوں کو براہ راست لکھ سکتے ہیں۔

لیکن کوڈ سے براہ راست جمع کرنے والوں کو لکھنا، stas-daemom کو نظرانداز کرتے ہوئے، ایک غیر تسلی بخش حل ہے کیونکہ اس سے کلکٹر پر بوجھ بڑھ جاتا ہے۔ حل صرف اس صورت میں موزوں ہے جب کسی وجہ سے ہم مشین پر memcache stats-daemon کو نہیں بڑھا سکتے، یا یہ کریش ہو گیا اور ہم براہ راست چلے گئے۔

اگلا، لاگز جمع کرنے والے اعداد و شمار کو اس میں ضم کرتے ہیں۔ meowDB - یہ ہمارا ڈیٹا بیس ہے، جو میٹرکس کو بھی اسٹور کر سکتا ہے۔

پھر ہم کوڈ سے بائنری "قریب ایس کیو ایل" کا انتخاب کر سکتے ہیں۔

تجربہ

2018 کے موسم گرما میں، ہمارے پاس ایک اندرونی ہیکاتھون تھا، اور خیال آیا کہ خاکے کے سرخ حصے کو کسی ایسی چیز سے تبدیل کرنے کی کوشش کی جائے جو کلک ہاؤس میں میٹرکس کو محفوظ کر سکے۔ ہمارے پاس کلک ہاؤس پر لاگ ہیں - کیوں نہ اسے آزمائیں؟

ہمارے پاس ایک اسکیم تھی جو KittenHouse کے ذریعے لاگ لکھتی تھی۔

ہم نے فیصلہ کیا۔ خاکہ میں ایک اور "*House" شامل کریں۔جو کہ فارمیٹ میں بالکل وہی میٹرکس وصول کرے گا جیسا کہ ہمارا کوڈ انہیں UDP کے ذریعے لکھتا ہے۔ پھر یہ *ہاؤس انہیں داخلوں میں بدل دیتا ہے، جیسے لاگز، جسے KittenHouse سمجھتا ہے۔ وہ ان نوشتہ جات کو ClickHouse تک پہنچا سکتا ہے، جو انہیں پڑھنے کے قابل ہونا چاہیے۔

memcache، stats-deemon اور logs-collectors کے ڈیٹا بیس کے ساتھ اسکیم کو اس سے بدل دیا گیا ہے۔

یہاں کوڈ سے ایک ڈسپیچ ہے، جو مقامی طور پر StatsHouse میں لکھا جاتا ہے۔
StatsHouse UDP میٹرکس لکھتا ہے، جو پہلے سے SQL انسرٹس میں تبدیل ہو چکا ہے، KittenHouse کو بیچوں میں۔
KittenHouse انہیں ClickHouse پر بھیجتا ہے۔
اگر ہم انہیں پڑھنا چاہتے ہیں، تو ہم انہیں StatsHouse کو نظرانداز کرتے ہوئے پڑھتے ہیں - براہ راست کلک ہاؤس سے باقاعدہ SQL کا استعمال کرتے ہوئے۔

کیا یہ اب بھی ہے؟ تجربہ، لیکن ہمیں یہ پسند ہے کہ یہ کیسے نکلتا ہے۔ اگر ہم اسکیم کے ساتھ مسائل کو حل کرتے ہیں، تو شاید ہم اسے مکمل طور پر تبدیل کردیں گے۔ ذاتی طور پر، مجھے امید ہے.

ڈرائیونگ لوہے کو محفوظ نہیں کرتا. کم سرورز کی ضرورت ہے، مقامی اعدادوشمار-ڈیمن اور لاگز جمع کرنے والوں کی ضرورت نہیں ہے، لیکن ClickHouse کو موجودہ اسکیم کے مقابلے میں ایک بڑے سرور کی ضرورت ہے۔ کم سرورز کی ضرورت ہے، لیکن وہ زیادہ مہنگے اور زیادہ طاقتور ہونے چاہئیں.

تعینات کریں۔

سب سے پہلے، آئیے پی ایچ پی کی تعیناتی کو دیکھتے ہیں۔ ہم میں ترقی کر رہے ہیں۔ گٹ: استعمال کریں۔ GitLab и ٹیمٹیئٹی تعیناتی کے لیے ڈیولپمنٹ برانچز کو ماسٹر برانچ میں ضم کر دیا جاتا ہے، ماسٹر سے ٹیسٹنگ میں ضم کر دیا جاتا ہے، اور سٹیجنگ سے پروڈکشن میں۔

تعیناتی سے پہلے، موجودہ پروڈکشن برانچ اور پچھلی ایک لی جاتی ہے، اور ان میں مختلف فائلوں پر غور کیا جاتا ہے - تبدیلیاں: تخلیق، حذف، تبدیل۔ یہ تبدیلی ایک خصوصی کاپی فاسٹ انجن کے بِن لاگ میں ریکارڈ کی جاتی ہے، جو ہمارے پورے سرور فلیٹ میں تبدیلیوں کو تیزی سے نقل کر سکتا ہے۔ یہاں جو چیز استعمال کی گئی ہے وہ براہ راست نقل نہیں ہے، لیکن گپ شپ کی نقل، جب ایک سرور اپنے قریبی پڑوسیوں کو تبدیلیاں بھیجتا ہے، وہ اپنے پڑوسیوں کو، وغیرہ۔ یہ آپ کو پورے بیڑے میں کوڈ کو دسیوں اور سیکنڈوں کی اکائیوں میں اپ ڈیٹ کرنے کی اجازت دیتا ہے۔ جب تبدیلی مقامی نقل تک پہنچتی ہے، تو یہ ان پیچ کو اس پر لاگو کرتا ہے۔ مقامی فائل سسٹم. رول بیک بھی اسی اسکیم کے مطابق کیا جاتا ہے۔

ہم کے پی ایچ پی کو بھی بہت زیادہ تعینات کرتے ہیں اور اس کی اپنی ترقی بھی ہوتی ہے۔ گٹ اوپر دیے گئے خاکے کے مطابق۔ اس کے بعد سے HTTP سرور بائنری، پھر ہم فرق پیدا نہیں کر سکتے ہیں - ریلیز بائنری کا وزن سینکڑوں MB ہے۔ لہذا، یہاں ایک اور آپشن ہے - ورژن کو لکھا گیا ہے۔ بن لاگ کاپی فاسٹ. ہر تعمیر کے ساتھ یہ بڑھتا ہے، اور رول بیک کے دوران یہ بھی بڑھتا ہے۔ ورژن سرورز پر نقل کیا گیا۔. مقامی کاپی فاسٹ دیکھتے ہیں کہ ایک نیا ورژن بِن لاگ میں داخل ہوا ہے، اور اسی گپ شپ کی نقل کے ذریعے وہ ہمارے ماسٹر سرور کو تھکائے بغیر، لیکن پورے نیٹ ورک پر بوجھ کو احتیاط سے پھیلاتے ہوئے، اپنے لیے بائنری کا تازہ ترین ورژن لیتے ہیں۔ کیا مندرجہ ذیل ہے مکرم دوبارہ لانچ نئے ورژن کے لیے۔

ہمارے انجنوں کے لیے، جو کہ بنیادی طور پر بائنری بھی ہیں، اسکیم بہت ملتی جلتی ہے:

گٹ ماسٹر برانچ؛
بائنری میں .deb;
ورژن binlog copyfast پر لکھا گیا ہے۔
سرورز پر نقل
سرور ایک تازہ .dep نکالتا ہے۔
dpkg -i;
شاندار نئے ورژن پر دوبارہ لانچ کریں۔

فرق یہ ہے کہ ہماری بائنری آرکائیوز میں پیک کی گئی ہے۔ .deb، اور جب وہ باہر پمپ کرتے ہیں۔ dpkg -i سسٹم پر رکھے گئے ہیں۔ kPHP کو بائنری کے طور پر کیوں تعینات کیا جاتا ہے، اور انجنوں کو dpkg کے طور پر تعینات کیا جاتا ہے؟ ایسا ہی ہوا۔ یہ کام کرتا ہے - اسے ہاتھ نہ لگائیں۔

کارآمد روابط:

انتون کیریوشکن کی رپورٹ "Vkontakte سسٹم ایڈمنسٹریٹر۔ کیسے؟" کاپی فاسٹ اور گپ شپ کے بارے میں تفصیلات کے ساتھ۔
یوری ناصردینوف کی رپورٹ "VK کس طرح دسیوں ہزار سرورز سے CLickHouse میں ڈیٹا داخل کرتا ہے".
میری رپورٹ "VKontakte کی مثال کا استعمال کرتے ہوئے ایک بڑھتے ہوئے منصوبے کا فن تعمیر"، لیکن ترقی کے نقطہ نظر سے، ہارڈ ویئر سے نہیں۔

الیکسی اکولووچ ان لوگوں میں سے ایک ہیں جو پروگرام کمیٹی کے حصے کے طور پر مدد کرتے ہیں۔ پی ایچ پی روس 17 مئی کو پی ایچ پی کے ڈویلپرز کے لیے حالیہ دنوں میں سب سے بڑا ایونٹ بن جائے گا۔ دیکھو ہمارے پاس کیا ٹھنڈا پی سی ہے، کیا ہے۔ مقررین (ان میں سے دو پی ایچ پی کور تیار کررہے ہیں!) - ایسا لگتا ہے کہ اگر آپ پی ایچ پی لکھتے ہیں تو آپ کو یاد نہیں ہوگا۔

ماخذ: www.habr.com

VKontakte کے فن تعمیر اور کام پر اکثر پوچھے گئے سوالات