د VKontakte د معمارۍ او کار په اړه FAQ

د VKontakte د جوړولو تاریخ په ويکيپېډيا کې دی؛ دا پخپله پاول وويل. داسې ښکاري چې هرڅوک دمخه هغه پیژني. په HighLoad++ Pavel کې د سایټ د داخلي، جوړښت او جوړښت په اړه ما په 2010 کې بیرته وویل. له هغه وخت راهیسې ډیری سرورونه لیک شوي ، نو موږ به معلومات تازه کړو: موږ به یې تحلیل کړو ، دننه به یې واخلو ، وزن یې وکړو او د تخنیکي نقطې څخه د VK وسیله وګورو.

الیکسي اکولوویچ (AterCattus) د VKontakte ټیم کې د پس منظر پراختیا کونکی. د دې راپور نقل د پلیټ فارم د عملیاتو، زیربنا، سرورونو او د دوی ترمنځ د متقابل عمل په اړه ډیری پوښتل شوي پوښتنو ته یو ګډ ځواب دی، مګر د پراختیا په اړه نه، د بیلګې په توګه. د اوسپنې په اړه. په جلا توګه، د ډیټابیسونو په اړه او د VK پرځای څه لري، د لاګونو راټولولو او په ټوله توګه د ټولې پروژې نظارت کولو په اړه. د کټ لاندې توضیحات.

د څلورو کلونو څخه ډیر وخت لپاره زه د پس منظر پورې اړوند هر ډول دندو سره معامله کوم.

• اپلوډ کول، ذخیره کول، پروسس کول، د رسنیو ویشل: ویډیو، ژوندی جریان، آډیو، عکسونه، اسناد.
• زیربنا، پلیټ فارم، د پراختیا کونکي څارنه، لاګ، سیمه ایز کیچ، CDN، ملکیت RPC پروتوکول.
• د بهرني خدماتو سره ادغام: خبرتیاوې فشار ورکول ، د بهرني لینک پارس کول ، RSS فیډ.
• د مختلفو پوښتنو سره د همکارانو سره مرسته کول، کوم ځوابونه چې په نامعلوم کوډ کې ډوبولو ته اړتیا لري.

د دې وخت په جریان کې، ما د سایټ په ډیرو برخو کې لاس درلود. زه غواړم دا تجربه شریکه کړم.

عمومي معمارۍ

هرڅه، د معمول په څیر، د سرور یا سرور ګروپ سره پیل کیږي چې غوښتنې مني.

مخکینۍ سرور

مخکښ سرور د HTTPS، RTMP او WSS له لارې غوښتنې مني.

HTTPS - دا د سایټ د اصلي او ګرځنده ویب نسخو لپاره غوښتنې دي: vk.com او m.vk.com، او زموږ د API نور رسمي او غیر رسمي پیرودونکي: ګرځنده پیرودونکي، میسینجر. موږ یو استقبال لرو RTMP- د جلا مخکښ سرورونو سره د ژوندیو خپرونو لپاره ترافیک او WSS- د سټیمینګ API لپاره اړیکې.

په سرورونو کې د HTTPS او WSS لپاره دا ارزښت لري نګینکس. د RTMP خپرونو لپاره، موږ پدې وروستیو کې خپل حل ته واړوو kive، مګر دا د راپور له دائرې څخه بهر دی. د غلطۍ زغملو لپاره، دا سرورونه عام IP پتې اعلانوي او په ګروپونو کې عمل کوي ترڅو که چیرې په یو سرور کې ستونزه وي، د کاروونکي غوښتنې له لاسه ورنکړل شي. د HTTPS او WSS لپاره، دا ورته سرورونه ټرافيک کوډ کوي ترڅو د CPU بار برخه پخپله واخلي.

موږ به د WSS او RTMP په اړه نور خبرې ونه کړو، مګر یوازې د معیاري HTTPS غوښتنو په اړه، کوم چې معمولا د ویب پروژې سره تړاو لري.

بډایډ

د مخ شاته معمولا د شاته سرورونه شتون لري. دوی غوښتنې پروسس کوي چې مخکښ سرور د پیرودونکو څخه ترلاسه کوي.

د دې د kPHP سرورونه، په کوم کې چې HTTP ډیمون روان دی ، ځکه چې HTTPS دمخه کوډ شوی دی. kPHP یو سرور دی چې پرمخ ځي prefork ماډلونه: د ماسټر پروسې پیل کوي، د ماشومانو پروسې یوه ډله، دوی ته د اوریدلو ساکټونه لیږدوي او دوی خپلې غوښتنې پروسس کوي. پدې حالت کې ، پروسې د کارونکي څخه د هرې غوښتنې ترمینځ نه پیل کیږي ، مګر په ساده ډول خپل حالت د اصلي صفر ارزښت حالت ته بیا تنظیم کړئ - د غوښتنې وروسته غوښتنه ، د بیا پیل کولو پرځای.

د بار ویش

زموږ ټول شاتړ د ماشینونو لوی حوض نه دی چې کولی شي هره غوښتنه پروسس کړي. موږ هغوی په جلا ډلو ویشل شوي دي: عمومي، ګرځنده، api، ویډیو، سټینګ... د ماشینونو په جلا ګروپ کې ستونزه به په نورو ټولو اغیزه ونکړي. د ویډیو سره د ستونزو په صورت کې، هغه کاروونکي چې میوزیک اوري حتی د ستونزو په اړه به نه پوهیږي. د غوښتنې لیږلو لپاره کوم شالید د ترتیب سره سم په مخ کې د نګینکس لخوا پریکړه کیږي.

د میټریک راټولول او بیا توازن کول

د دې لپاره چې پوه شو چې موږ په هر ګروپ کې څومره موټرو ته اړتیا لرو په QPS تکیه مه کوئ. پستونه مختلف دي، دوی مختلف غوښتنې لري، هره غوښتنه د QPS محاسبه کولو مختلف پیچلتیا لري. له همدې امله موږ موږ په بشپړ ډول په سرور کې د بار مفهوم سره کار کوو - په CPU او perf کې.

موږ په زرګونو داسې سرورونه لرو. هر فزیکي سرور د kPHP ګروپ چلوي ترڅو ټول کورونه ریسایکل کړي (ځکه چې kPHP واحد تار شوی دی).

د منځپانګې سرور

CS یا د منځپانګې سرور یو ذخیره ده. 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 ورکړو، او "خړ" ورکړئ. پدې توګه موږ په IP حوض کې خوندي کړل او تضمین یې وکړ چې ماشینونه د بهر لاسرسي څخه ساتي - دلته د ننوتلو لپاره په ساده ډول هیڅ IP شتون نلري.

د شریک شوي IPs په اړه مقاومت. د غلطۍ زغم په شرایطو کې، سکیم ورته کار کوي - ډیری فزیکي سرورونه یو عام فزیکي IP لري، او د دوی په وړاندې هارډویر غوره کوي چې غوښتنه چیرته واستوي. زه به وروسته د نورو اختیارونو په اړه وغږیږم.

متنازع ټکی دا دی چې په دې قضیه کې پیرودونکي لږ اړیکې ساتي. که چیرې د څو ماشینونو لپاره ورته IP شتون ولري - د ورته کوربه سره: pu.vk.com یا pp.vk.com، د پیرودونکي براوزر یو کوربه ته د ورته غوښتنو شمیر محدودیت لري. مګر د هر اړخیز HTTP/2 په وخت کې، زه باور لرم چې دا نور دومره اړونده ندي.

د سکیم ښکاره نیمګړتیا دا ده چې دا باید ولري ټول ټرافیک پمپ کړئ، کوم چې ذخیره ته ځي، د بل سرور له لارې. څرنګه چې موږ ټرافيک د ماشینونو له لارې پمپ کوو، موږ لاهم د ورته سکیم په کارولو سره دروند ټرافیک پمپ نشو کولی، د بیلګې په توګه، ویډیو. موږ دا په مستقیم ډول لیږدوو - د جلا جلا ذخیره کولو لپاره په ځانګړې توګه د ویډیو لپاره جلا مستقیم اړیکه. موږ سپک مواد د پراکسي له لارې لیږدوو.

ډیر وخت دمخه موږ د پراکسي ښه نسخه ترلاسه کړه. اوس زه به تاسو ته ووایم چې دوی څنګه له عادي څخه توپیر لري او ولې دا اړینه ده.

Sun

په سپتمبر 2017 کې، اوریکل، چې مخکې یې سن اخیستی و، د لمر لوی شمیر کارمندان له دندو ګوښه کړل. موږ کولی شو ووایو چې پدې وخت کې د شرکت شتون پای ته رسیدلی. کله چې د نوي سیسټم لپاره نوم وټاکو، زموږ مدیرانو پریکړه وکړه چې د دې شرکت یاد ته درناوی وکړي او د نوي سیسټم نوم یې سن ته ورکړ. زموږ په منځ کې موږ په ساده ډول هغې ته "لمر" وایو.

pp یو څو ستونزې درلودې. په هر ګروپ کې یو IP - غیر موثر کیچ. ډیری فزیکي سرورونه یو عام IP پته شریکوي، او د کنټرول لپاره کومه لاره نشته چې کوم سرور ته غوښتنه وشي. نو ځکه، که مختلف کاروونکي د ورته فایل لپاره راځي، نو که چیرې په دې سرورونو کې کیچ شتون ولري، فایل د هر سرور په کیچ کې پای ته رسیږي. دا یو ډیر غیر موثر سکیم دی، مګر هیڅ شی نشي ترسره کیدی.

په پایله کې - موږ محتوا نه شو کولی، ځکه چې موږ نشو کولی د دې ډلې لپاره یو ځانګړی سرور غوره کړو - دوی یو عام IP لري. همدارنګه د ځینو داخلي دلایلو لپاره موږ لرو دا ممکنه نه وه چې دا ډول سرورونه په سیمو کې نصب شي. دوی یوازې په سینټ پیټرزبورګ کې ولاړ وو.

د لمر سره، موږ د انتخاب سیسټم بدل کړ. اوس موږ لرو هر کاسټ لاره: متحرک روټینګ، هر کاسټ، د ځان چک ډیمون. هر سرور خپل انفرادي IP لري، مګر یو عام سبنټ. هرڅه په داسې ډول تنظیم شوي چې که یو سرور ناکام شي ، ترافیک په اوتومات ډول د ورته ګروپ نورو سرورونو ته خپریږي. اوس دا ممکنه ده چې یو ځانګړی سرور غوره کړئ، بې ځایه کیشینګ نشته، او اعتبار نه دی اغیزمن شوی.

د وزن ملاتړ. اوس موږ کولی شو د اړتیا سره سم د مختلف بریښنا ماشینونه نصب کړو ، او همدارنګه د لنډمهاله ستونزو په صورت کې د کار کولو "لمر" وزنونه بدل کړئ ترڅو دوی باندې بار کم کړي ، ترڅو دوی "آرام" وکړي او بیا کار پیل کړي.

د مینځپانګې ID لخوا شریکول. د شارډینګ په اړه یو مسخره شی: موږ معمولا مینځپانګه شارږو ترڅو مختلف کارونکي د ورته "لمر" له لارې ورته فایل ته لاړ شي ترڅو دوی یو عام کیچ ولري.

موږ پدې وروستیو کې د "کلور" غوښتنلیک پیل کړ. دا په ژوندۍ خپرونه کې آنلاین کوئز دی ، چیرې چې کوربه پوښتنې کوي او کارونکي په ریښتیني وخت کې ځوابونه ورکوي ، د اختیارونو غوره کول. ایپ یو چیټ لري چیرې چې کاروونکي کولی شي خبرې وکړي. کولی شي په ورته وخت کې د خپرونې سره وصل شي له 100 زرو څخه ډیر خلک. دوی ټول هغه پیغامونه لیکي چې ټولو ګډون کونکو ته لیږل کیږي، او یو اوتار د پیغام سره راځي. که په یوه "لمر" کې 100 زره خلک د یو اوتار لپاره راشي، نو دا ځینې وختونه د ورېځې شاته ګرځي.

د ورته فایل لپاره د غوښتنو د ډیریدو سره د مقابلې لپاره ، دا د یو ځانګړي ډول مینځپانګې لپاره دی چې موږ یو احمقانه سکیم فعال کوو چې فایلونه په سیمه کې په ټولو موجود "لمر" کې خپروي.

لمر له دننه څخه

په نګینکس کې ریورس پراکسي ، کیچ یا په رام کې یا په ګړندۍ آپټاین / NVMe ډیسکونو کې. بېلګه: http://sun4-2.userapi.com/c100500/path - د "لمر" لینک، چې په څلورمه سیمه کې موقعیت لري، د دویم سرور ګروپ. دا د لارې فایل بندوي، کوم چې په فزیکي توګه په سرور 100500 کې پروت دی.

پوښ

موږ زموږ د معمارۍ سکیم ته یو بل نوډ اضافه کوو - د کیشینګ چاپیریال.

لاندې د ترتیب ډیاګرام دی سیمه ایز کیچ، د دوی شاوخوا 20 شتون لري. دا هغه ځایونه دي چیرې چې کیچونه او "لمر" موقعیت لري، کوم چې کولی شي د ځان له لارې ټرافيک ذخیره کړي.

دا د ملټي میډیا مینځپانګې کیچ کول دي؛ دلته د کارونکي هیڅ معلومات ندي زیرمه شوي - یوازې میوزیک ، ویډیو ، عکسونه.

د کارونکي سیمه ټاکلو لپاره، موږ موږ په سیمو کې اعلان شوي د BGP شبکې مختګونه راټولوو. د فال بیک په حالت کې، موږ باید د جیوپ ډیټابیس هم تجزیه کړو که چیرې موږ د مخکینیو مخونو لخوا IP ونه موندلو. موږ سیمه د کارونکي IP لخوا مشخص کوو. په کوډ کې، موږ کولی شو د کارونکي یو یا څو سیمې وګورو - هغه ټکي چې هغه په ​​​​جغرافیه کې نږدې دی.

دا څنګه کار کوي؟

موږ د سیمې له مخې د فایلونو شهرت حسابوو. دلته یو شمیر سیمه ایز کیچ شتون لري چیرې چې کارن موقعیت لري ، او د فایل پیژندونکی - موږ دا جوړه اخلو او د هر ډاونلوډ سره درجه بندي ډیروو.

په ورته وخت کې ، شیطانان - په سیمو کې خدمات - وخت په وخت API ته راځي او وايي: "زه داسې او داسې کیچ یم ، ماته زما په سیمه کې د خورا مشهور فایلونو لیست راکړئ چې لاهم په ما کې ندي. » API د درجې له مخې ترتیب شوي د فایلونو ډله وړاندې کوي، ډیمون یې ډاونلوډ کوي، سیمو ته یې لیږي او له هغه ځایه فایلونه وړاندې کوي. دا د کیچ څخه د pu/pp او سن ترمینځ اساسی توپیر دی: دوی سمدلاسه فایل پخپله ورکوي ، حتی که دا فایل په کیچ کې نه وي ، او کیچ لومړی فایل پخپله ډاونلوډ کوي ، او بیا یې بیرته ورکول پیل کوي.

پدې حالت کې موږ ترلاسه کوو مینځپانګه کاروونکو ته نږدې او د شبکې بار خپرول. د مثال په توګه، یوازې د مسکو کیچ څخه موږ د لوړ ساعت په جریان کې له 1 Tbit/s څخه ډیر توزیع کوو.

مګر ستونزې شتون لري - د کیچ سرورونه ربړ ندي. د عالي مشهور مینځپانګې لپاره ، ځینې وختونه د جلا سرور لپاره کافي شبکه شتون نلري. زموږ د کیچ سرورونه 40-50 Gbit/s دي ، مګر داسې مینځپانګه شتون لري چې دا ډول چینل په بشپړ ډول بندوي. موږ په سیمه کې د مشهور فایلونو څخه د ډیرو کاپي ذخیره کولو پلي کولو په لور حرکت کوو. زه امید لرم چې موږ به یې د کال تر پایه پلي کړو.

موږ عمومي معمارۍ ته وکتل.

• مخکینۍ سرورونه چې غوښتنې مني.
• د پروسې غوښتنې ملاتړ کوي.
• هغه ذخیره چې د دوه ډوله پراکسي لخوا تړل شوي.
• سیمه ایز کیچونه.

د دې انځور څخه څه ورک دي؟ البته، هغه ډیټابیسونه چې موږ پکې ډاټا ذخیره کوو.

ډیټابیسونه یا انجنونه

موږ دوی ته ډیټابیس نه بولو، مګر انجنونه - انجنونه، ځکه چې موږ په عملي توګه په عمومي توګه منل شوي مفهوم کې ډیټابیس نلرو.

دا یو اړین اقدام دی. دا پیښ شوي ځکه چې په 2008-2009 کې، کله چې VK په شهرت کې چاودیدونکي وده درلوده، پروژه په بشپړ ډول په MySQL او Memcache کې کار کاوه او ستونزې شتون درلود. مای ایس کیو ایل د فاسدو او فاسدو فایلونو سره مینه درلوده، وروسته له دې چې دا به بیرته نه راګرځي، او میمکیچ په تدریجي ډول په فعالیت کې خراب شوی او باید بیا پیل شي.

دا معلومه شوه چې په زیاتیدونکي توګه مشهوره پروژه دوامداره ذخیره درلوده، کوم چې ډاټا فاسد کوي، او یو زیرمه، چې ورو کیږي. په داسې شرایطو کې، د ودې پروژې پراختیا ستونزمنه ده. پریکړه وشوه چې هغه مهم شیان بیا لیکلو هڅه وکړو چې پروژه زموږ په خپل بایسکل باندې متمرکزه وه.

د حل لاره بریالۍ وه. د دې کولو لپاره یو فرصت هم شتون درلود، او همدارنګه خورا اړین اړتیا وه، ځکه چې په هغه وخت کې د اندازه کولو نورې لارې شتون نه درلود. دلته د ډیټابیسونو ډله نه وه، NoSQL لا شتون نه درلود، یوازې MySQL، Memcache، PostrgreSQL شتون درلود - او دا دی.

نړیوال عملیات. پرمختګ زموږ د C پراختیا کونکو ټیم لخوا رهبري کیده او هرڅه په منظم ډول ترسره شوي. د انجن په پام کې نیولو پرته، دوی ټول نږدې ورته فایل فارمیټ درلود چې ډیسک ته لیکل شوي، ورته لانچ پیرامیټونه، په ورته ډول پروسس شوي سیګنالونه، او د څنډې حالتونو او ستونزو په صورت کې نږدې ورته چلند کوي. د انجنونو د ودې سره، دا د مدیرانو لپاره د سیسټم چلولو لپاره اسانه دی - هیڅ داسې ژوبڼ شتون نلري چې باید وساتل شي، او دوی باید د هر نوي دریمې ډلې ډیټابیس چلولو څرنګوالی زده کړي، کوم چې دا ممکنه کړې چې په چټکه او اسانۍ سره وده ومومي. د هغوی شمیر.

د انجنونو ډولونه

ټیم یو څو انجنونه لیکلي. دلته یوازې یو څه دي: ملګري، اشارې، عکس، ipdb، لیکونه، لیستونه، لاګونه، memcached، meowdb، خبرونه، nostradamus، انځور، پلی لیستونه، pmemcached، سانډ باکس، لټون، ذخیره کول، خوښې، دندې، ...

د هرې دندې لپاره چې ځانګړي ډیټا جوړښت ته اړتیا لري یا غیر معمولي غوښتنې پروسس کوي ، د C ټیم نوی انجن لیکي. ولې نه.

موږ یو جلا انجن لرو منل شوی، کوم چې د منظم سره ورته دی ، مګر د ښه شیانو سره ، او کوم چې ورو نه کیږي. نه ClickHouse، خو دا هم کار کوي. په جلا توګه شتون لري pemcached دی دوامداره 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 سکیما اختیاري ساحې، پیچلي ډولونه - د جوړ شوي سکالرونو غزول، او پوښتنې وړاندې کوي. هر څه د دې پروتوکول مطابق کار کوي.

RPC د TL پر TCP/UDP… UDP؟

موږ د انجن غوښتنې پلي کولو لپاره د RPC پروتوکول لرو چې د TL سکیم په سر کې تیریږي. دا ټول د TCP/UDP اتصال له لارې کار کوي. TCP د پوهیدو وړ دی، مګر ولې موږ ډیری وختونه UDP ته اړتیا لرو؟

UDP مرسته کوي د سرورونو تر مینځ د لوی شمیر اړیکو ستونزې څخه مخنیوی وکړئ. که هر سرور د RPC پراکسي ولري او په عموم کې، دا کولی شي هر انجن ته لاړ شي، نو په هر سرور کې په لسګونو زره TCP اړیکې شتون لري. یو بار شتون لري، مګر دا بې ګټې دی. د UDP په قضیه کې دا ستونزه شتون نلري.

هیڅ بې ځایه TCP لاسونه نشته. دا یوه عادي ستونزه ده: کله چې یو نوی انجن یا نوی سرور پیل شي، ډیری TCP پیوستون په یوځل کې رامینځته کیږي. د کوچنیو سپکو غوښتنو لپاره، د بیلګې په توګه، د UDP پیلډ، د کوډ او انجن تر مینځ ټول ارتباطات دي دوه UDP کڅوړې: یو په یو لوري پرواز کوي، دویم په بل لوري. یو پړاو سفر - او کوډ پرته له لاس اخیستو څخه د انجن څخه ځواب ترلاسه کړ.

هو، دا ټول یوازې کار کوي د پاکټ له لاسه ورکولو خورا لږ فیصدي سره. پروتوکول د بیا لیږد او وخت پای ته رسیدو لپاره ملاتړ لري، مګر که موږ ډیر څه له لاسه ورکړو، موږ به نږدې TCP ترلاسه کړو، کوم چې ګټور نه دی. موږ د بحرونو په اوږدو کې UDP نه چلوو.

موږ په زرګونو داسې سرورونه لرو، او سکیم ورته دی: د انجنونو یوه بسته په هر فزیکي سرور کې نصب شوې. دوی اکثرا واحد تار شوي دي ترڅو ژر تر ژره پرته له بلاک کولو څخه وګرځي ، او د واحد تار شوي حلونو په توګه شارډ شوي. په ورته وخت کې، موږ د دې انجنونو په پرتله د اعتبار وړ بل څه نه لرو، او د دوامداره معلوماتو ذخیره کولو ته ډیره پاملرنه کیږي.

د دوامداره معلوماتو ذخیره کول

انجنونه بنلاګونه لیکي. بنلاګ یوه فایل دی چې په پای کې د حالت یا ډیټا د بدلون لپاره پیښه اضافه کیږي. په مختلفو حلونو کې دا په بل ډول ویل کیږي: بائنری لاګ، وال, AFخو اصل یو شان دی.

د دې لپاره چې انجن د ډیری کلونو لپاره د بشپړ بنلاګ بیا لوستلو څخه مخنیوی وکړي کله چې بیا پیل شي، انجنونه لیکي عکسونه - اوسنی حالت. که اړتیا وي، دوی لومړی له هغې څخه لولي، او بیا د بنلاګ څخه لوستل پای ته رسوي. ټول بنلاګونه په ورته بائنری شکل کې لیکل شوي - د TL سکیم سره سم، نو دا چې مدیران کولی شي دوی د دوی وسیلو سره مساوي اداره کړي. داسې انځورونو ته اړتیا نشته. یو عمومي سرلیک شتون لري چې دا په ګوته کوي چې د چا سنیپ شاټ int دی، د انجن جادو، او کوم بدن د هیچا لپاره مهم ندي. دا د انجن سره ستونزه ده چې سنیپ شاټ یې ثبت کړی.

زه به ژر تر ژره د عملیاتو اصول بیان کړم. یو سرور شتون لري چې انجن چلوي. هغه د لیکلو لپاره یو نوی خالي بنلاګ پرانیزي او د بدلون لپاره پیښه لیکي.

په ځینو وختونو کې، هغه یا پریکړه کوي چې پخپله یو سنیپ شاټ واخلي، یا هغه سیګنال ترلاسه کړي. سرور یوه نوې فایل جوړوي، خپل ټول حالت په کې لیکي، د اوسني بنلاګ اندازه - آفسیټ - د فایل پای ته ضمیمه کوي، او نور لیکلو ته دوام ورکوي. نوی بنلاګ نه دی جوړ شوی.

په یو وخت کې، کله چې انجن بیا پیل شي، په ډیسک کې به یو بنلاګ او سنیپ شاټ دواړه وي. انجن ټول سنیپ شاټ لولي او په یو ټاکلي وخت کې خپل حالت لوړوي.

هغه موقعیت ولولئ چې د سنیپ شاټ په وخت کې و او د بنلاګ اندازه.

د اوسني حالت ترلاسه کولو لپاره د بنلاګ پای لوستل او د نورو پیښو لیکلو ته دوام ورکوي. دا یو ساده سکیم دی؛ زموږ ټول انجنونه د هغې سره سم کار کوي.

د معلوماتو نقل کول

د پایلې په توګه، زموږ کې د معلوماتو نقل کول د بیان پر بنسټ - موږ په بنلاګ کې لیکو چې په پاڼه کې هیڅ بدلون نه راځي، مګر نوم غوښتنې بدل کړئ. د هغه څه سره ورته چې په شبکه کې راځي، یوازې یو څه بدل شوی.

ورته سکیم نه یوازې د نقل لپاره کارول کیږي، بلکې هم د بیک اپ جوړولو لپاره. موږ یو انجن لرو - د لیکلو ماسټر چې بنلاګ ته لیکي. په کوم بل ځای کې چې مدیران یې تنظیم کړي، دا بنلاګ کاپي شوی، او دا دی - موږ یو بیک اپ لرو.

که اړتیا وه د لوستلو نقلد CPU لوستلو بار کمولو لپاره، د لوستلو انجن په ساده ډول پیل شوی، کوم چې د بنلاګ پای لوستل کوي او دا قوماندې په ځایی توګه اجرا کوي.

دلته وقف خورا کوچنی دی ، او دا ممکنه ده چې ومومئ چې نقل څومره د ماسټر شاته پاتې دی.

په RPC پراکسي کې د معلوماتو شریکول

شارډینګ څنګه کار کوي؟ پراکسي څنګه پوهیږي چې کوم کلستر شارډ ته لیږل کیږي؟ کوډ نه وايي: "د 15 شارډونو لپاره لیږئ!" - نه، دا د پراکسي لخوا ترسره کیږي.

ترټولو ساده سکیم لومړی دی - په غوښتنه کې لومړی نمبر.

get(photo100_500) => 100 % N.

دا د ساده memcached متن پروتوکول لپاره یوه بیلګه ده، مګر، البته، پوښتنې پیچلې او جوړښت کیدی شي. مثال په پوښتنه کې لومړی نمبر اخلي او پاتې کله چې د کلستر اندازې سره ویشل کیږي.

دا ګټور دی کله چې موږ غواړو د یوې واحدې ډیټا ځای ولرو. راځئ چې ووایو 100 یو کارن یا ګروپ ID دی، او موږ غواړو چې د یوې ادارې ټول معلومات د پیچلو پوښتنو لپاره په یوه برخه کې وي.

که موږ پروا نه کوو چې غوښتنې څنګه په ټول کلستر کې خپریږي، یو بل اختیار شتون لري - ټوله شارډ هش کول.

hash(photo100_500) => 3539886280 % N

موږ هش، د ویش پاتې برخه او د شارډ شمیره هم ترلاسه کوو.

دا دواړه اختیارونه یوازې هغه وخت کار کوي چې موږ د دې حقیقت لپاره چمتو یو چې کله موږ د کلستر اندازه زیاته کړو، موږ به یې تقسیم کړو یا څو ځله یې زیات کړو. د مثال په توګه، موږ 16 شارډونه درلودل، موږ کافي نلرو، موږ نور غواړو - موږ کولی شو په خوندي ډول 32 پرته له ځنډ څخه ترلاسه کړو. که موږ غواړو چې ضربونه زیات کړو، نو د وخت وخت به وي، ځکه چې موږ به نشو کولی هر څه د زیانونو پرته په سمه توګه وویشو. دا اختیارونه ګټور دي، مګر تل نه.

که موږ اړتیا لرو چې د سرورونو خپل سري شمیر اضافه یا لرې کړو، موږ کاروو په حلقه a la Ketama کې دوامداره هش کول. مګر په ورته وخت کې، موږ د معلوماتو ځای په بشپړه توګه له لاسه ورکوو؛ موږ باید غوښتنه په کلستر کې ضمیمه کړو ترڅو هره ټوټه خپل کوچنی غبرګون بیرته راولي، او بیا ځوابونه پراکسي سره یوځای کړي.

خورا ځانګړي غوښتنې شتون لري. دا داسې ښکاري: RPC پراکسي غوښتنه ترلاسه کوي، ټاکي چې کوم کلستر ته لاړ شي او شارډ ټاکي. بیا یا د لیکلو ماسټران شتون لري، یا که کلستر د نقل ملاتړ ولري، دا د غوښتنې سره سم نقل ته لیږي. پراکسي دا ټول کوي.

لوګو

موږ لاګونه په څو لارو لیکو. ترټولو څرګند او ساده دی memcache ته لاګونه ولیکئ.

ring-buffer: prefix.idx = line

دلته یو کلیدي مختاړی دی - د لاګ نوم، یوه کرښه، او د دې لاګ اندازه شتون لري - د لیکو شمیر. موږ یو تصادفي شمیره له 0 څخه د لینونو شمیره منفي 1 ته اخلو. په میم کیچ کې کیلي د دې تصادفي شمیرې سره یو مخ مختاړی دی. موږ د لاګ لاین او اوسنی وخت ارزښت ته خوندي کوو.

کله چې د لوګو لوستلو ته اړتیا وي، موږ یې ترسره کوو ملټي ترلاسه کول ټولې کیلي، د وخت په واسطه ترتیب شوي، او پدې توګه په ریښتیني وخت کې د تولید لاګ ترلاسه کړئ. سکیم کارول کیږي کله چې تاسو اړتیا لرئ په ریښتیني وخت کې تولید کې یو څه ډیبګ کړئ ، پرته لدې چې هیڅ شی مات کړئ ، پرته له ځنډولو یا نورو ماشینونو ته ترافیک ته اجازه ورکړئ ، مګر دا لاګ ډیر دوام نه کوي.

د لاګونو د باور وړ ذخیره کولو لپاره موږ انجن لرو log-engine. دا دقیقا ولې دا رامینځته شوی او په پراخه کچه په ډیری کلسترونو کې کارول کیږي. ترټولو لوی کلستر چې زه پوهیږم د 600 TB بسته شوي لاګ ذخیره کوي.

انجن ډیر زوړ دی، دلته کلسترونه شتون لري چې دمخه یې 6-7 کلن دي. پدې کې ستونزې شتون لري چې موږ یې د حل کولو هڅه کوو، د بیلګې په توګه، موږ د لاګونو ذخیره کولو لپاره په فعاله توګه د ClickHouse کارولو پیل وکړ.

په ClickHouse کې د لاګونو راټولول

دا ډیاګرام ښیې چې موږ څنګه زموږ انجنونو ته ځو.

داسې کوډ شتون لري چې په محلي توګه د RPC له لارې RPC-proxy ته ځي، او دا پوهیږي چې انجن ته چیرته ځي. که موږ غواړو په ClickHouse کې لاګونه ولیکو، موږ باید په دې سکیم کې دوه برخې بدل کړو:

• د کلک هاؤس سره یو څه انجن بدل کړئ؛
• د RPC پراکسي بدل کړئ، کوم چې نشي کولی ClickHouse ته لاسرسی ومومي، د ځینې حل سره چې کولی شي، او د RPC له لارې.

انجن ساده دی - موږ دا د کلک هاوس سره د سرور یا د سرورونو کلستر سره بدلوو.

او کلیک هاوس ته د تګ لپاره، موږ وکړل کیټین هاوس. که موږ مستقیم له KittenHouse څخه ClickHouse ته لاړ شو، دا به مقابله ونه کړي. حتی د غوښتنو پرته، دا د ډیری ماشینونو HTTP اړیکو څخه اضافه کوي. د سکیم د کار کولو لپاره، په سرور کې د ClickHouse سره محلي ریورس پراکسي پورته کیږي، کوم چې په داسې ډول لیکل شوی چې دا کولی شي د اتصال اړین حجمونو سره مقاومت وکړي. دا کولی شي په خپل ځان کې په نسبتا معتبر ډول ډاټا بفر کړي.

ځینې ​​​​وختونه موږ نه غواړو د RPC سکیم په غیر معیاري حلونو کې پلي کړو، د بیلګې په توګه، په نګینکس کې. له همدې امله، KittenHouse د UDP له لارې د لاګونو ترلاسه کولو وړتیا لري.

که چیرې د لاګونو لیږونکی او ترلاسه کونکی په ورته ماشین کې کار وکړي، نو په محلي کوربه کې د UDP پاکټ له لاسه ورکولو احتمال خورا ټیټ دی. د دریمې ډلې حل او اعتبار کې د RPC پلي کولو اړتیا ترمینځ د جوړجاړي په توګه ، موږ په ساده ډول د UDP لیږلو څخه کار اخلو. موږ به وروسته دې سکیم ته راستون شو.

څارنه

موږ دوه ډوله لاګونه لرو: هغه چې د دوی په سرورونو کې د مدیرانو لخوا راټول شوي او د کوډ څخه د پراختیا کونکو لخوا لیکل شوي. دوی د دوه ډوله میټریکونو سره مطابقت لري: سیسټم او محصول.

د سیسټم میترونه

دا زموږ په ټولو سرورونو کار کوي نټټاټا، کوم چې احصایې راټولوي او دوی ته یې لیږي ګرافیت کاربن. له همدې امله، ClickHouse د ذخیره کولو سیسټم په توګه کارول کیږي، او نه ویسپر، د بیلګې په توګه. که اړتیا وي، تاسو کولی شئ مستقیم له ClickHouse څخه ولولئ، یا وکاروئ ګرافانا د میټریکونو، ګرافونو او راپورونو لپاره. د پراختیا کونکو په توګه، موږ Netdata او Grafana ته کافي لاسرسی لرو.

د محصول اندازه

د اسانتیا لپاره، موږ ډیری شیان لیکلي دي. د مثال په توګه، د عادي دندو یوه مجموعه شتون لري چې تاسو ته اجازه درکوي په احصایو کې د شمیرو، یونیک شمیرو ارزښتونه ولیکئ، کوم چې بل چیرې لیږل کیږي.

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 ټول ریکارډونه راټولوي. بیا، شیطان میټریکونه د سرورونو په دوه پرتونو کې یوځای کوي logs-collectors، کوم چې زموږ د ماشینونو له ډلې څخه احصایې راټولوي ترڅو د دوی شاته پرت مړ نشي.

که اړتیا وي، موږ کولی شو مستقیم د لاګ راټولونکو ته ولیکئ.

مګر د کوډ څخه مستقیم راټولونکو ته لیکل ، د سټاس ډیموم په تیریدو سره ، د توزیع وړ ضعیف حل دی ځکه چې دا په راټولونکي باندې بار زیاتوي. حل یوازې هغه وخت مناسب دی چې د کوم دلیل لپاره موږ نشو کولی په ماشین کې د memcache stats-deemon پورته کړو، یا دا ټکر شو او موږ مستقیم لاړ شو.

بیا، د لاګ راټولونکي احصایې په کې ضم کوي meowDB - دا زموږ ډیټابیس دی، کوم چې کولی شي میټریکونه هم ذخیره کړي.

بیا موږ کولی شو د کوډ څخه بائنری "نژدې-SQL" انتخابونه وکړو.

تجربه

د 2018 په دوبي کې، موږ یو داخلي هیکاتون درلود، او دا مفکوره راغله چې د ډیاګرام سور برخه د هغه څه سره بدله کړئ چې کولی شي په کلیک هاوس کې میټریکونه ذخیره کړي. موږ په ClickHouse کې لاګونه لرو - ولې دا هڅه نه کوئ؟

موږ یو سکیم درلود چې د KittenHouse له لارې لاګونه لیکلي.

موږ پریکړه وکړه په ډیاګرام کې بل "*کور" اضافه کړئ، کوم چې به په سمه توګه میټریکونه په شکل کې ترلاسه کړي ځکه چې زموږ کوډ دوی د UDP له لارې لیکي. بیا دا * کور دوی په داخلونو بدلوي ، لکه د لاګونو په څیر ، کوم چې کیټین هاوس پوهیږي. هغه کولی شي په بشپړ ډول دا لاګونه ClickHouse ته ورسوي، کوم چې باید د لوستلو وړ وي.

د memcache، stats-deemon او logs-collectors ډیټابیس سره سکیم د دې سره بدل شوی.

د memcache، stats-deemon او logs-collectors ډیټابیس سره سکیم د دې سره بدل شوی.

• دلته د کوډ څخه لیږل شتون لري، کوم چې په محلي توګه په StatsHouse کې لیکل شوی.
• سټیټس هاؤس د UDP میټریکونه لیکي ، چې دمخه د ایس کیو ایل داخلونو کې بدل شوي ، په بیچونو کې کیټین هاؤس ته.
• KittenHouse دوی ClickHouse ته لیږي.
• که موږ غواړو دوی ولولو، نو موږ یې د StatsHouse له لارې لوستلو - مستقیم د کلک هاوس څخه د منظم SQL په کارولو سره.

ایا دا لاهم دی تجربه، مګر موږ خوښوو چې دا څنګه پیښیږي. که موږ د سکیم سره ستونزې حل کړو ، نو شاید موږ به دې ته په بشپړ ډول تیر شو. په شخصي توګه، زه هیله لرم.

دا پلان اوسپنه نه خوندي کوي. لږ سرورونو ته اړتیا ده، محلي احصایې - ډیمونونه او لاګ - راټولونکي اړتیا نلري، مګر کلیک هاوس د اوسني سکیم په پرتله لوی سرور ته اړتیا لري. لږ سرورونو ته اړتیا ده، مګر دوی باید ډیر ګران او ډیر پیاوړي وي.

ګمارل

لومړی، راځئ چې د PHP ګمارنې ته وګورو. موږ په کې پرمختګ کوو لاړ شه: استعمال ګیتاباب и ډله ټکی د ګمارنې لپاره. پراختیایي څانګې په ماسټر برانچ کې یوځای کیږي، د ماسټر څخه د ازموینې لپاره دوی په سټینګ کې، او له سټینګ څخه تولید ته یوځای کیږي.

د ځای په ځای کولو دمخه ، د تولید اوسنی څانګه او مخکینۍ برخه اخیستل کیږي ، او مختلف فایلونه په پام کې نیول شوي - بدلونونه: رامینځته شوي ، حذف شوي ، بدل شوي. دا بدلون د ځانګړي کاپي فاسټ انجن په بنلاګ کې ثبت شوی، کوم چې کولی شي په چټکۍ سره زموږ په ټول سرور بیړۍ کې بدلونونه نقل کړي. هغه څه چې دلته کارول کیږي مستقیم کاپي کول ندي، مګر د خپګان نقل، کله چې یو سرور خپلو نږدې ګاونډیانو ته بدلونونه لیږي ، هغه خپلو ګاونډیو ته ، او داسې نور. دا تاسو ته اجازه درکوي په ټوله بیړۍ کې کوډ په لسګونو او د ثانیو واحدونو کې تازه کړئ. کله چې بدلون محلي نقل ته ورسیږي، دا دا پیچونه په هغې کې پلي کوي د محلي فایل سیسټم. رول بیک هم د ورته سکیم سره سم ترسره کیږي.

موږ د kPHP ډیر ځای په ځای کوو او دا هم خپل پرمختګ لري لاړ شه د پورته ډیاګرام مطابق. له دې څخه د HTTP سرور بائنری، بیا موږ نشو کولی توپیر تولید کړو - د خوشې کولو بائنری په سلګونو MB وزن لري. له همدې امله، دلته یو بل اختیار شتون لري - نسخه لیکل شوې ده binlog copyfast. د هر جوړیدو سره دا وده کوي، او د رول بیک په جریان کې دا هم وده کوي. نسخه سرورونو ته نقل شوی. ځایی کاپي فاسټونه ګوري چې نوې نسخه بنلاګ ته ننوتلې ، او د ورته ګپ شپ نقل سره دوی د بائنری وروستۍ نسخه د ځان لپاره اخلي ، پرته له دې چې زموږ ماسټر سرور ستړي کړي ، مګر په احتیاط سره په ټوله شبکه کې بار خپروي. څه تعقیبوي په زړه پوری بیا پیل کول د نوې نسخې لپاره.

زموږ د انجنونو لپاره، کوم چې په اصل کې بائنری هم دي، سکیم خورا ورته دی:

• د git ماسټر څانګه؛
• په بائنری کې .deb;
• نسخه د بنلاګ کاپي فاسټ ته لیکل شوې؛
• سرورونو ته نقل شوی؛
• سرور تازه .dep راوباسي؛
• dpkg -i;
• په زړه پوری نوي نسخه ته بیا پیل کول.

توپیر دا دی چې زموږ بائنری په آرشیف کې بسته شوی .deb، او کله چې دوی پمپ کوي dpkg -i په سیسټم کې ځای پر ځای شوي دي. ولې kPHP د بائنری په توګه ګمارل شوی، او انجنونه د dpkg په توګه ګمارل شوي؟ همداسې وشول. دا کار کوي - لاس مه ورکوئ.

ګټور لینکونه:

• د انتون کیریوشکین لخوا راپور د Vkontakte سیسټم مدیر. هغه څنګه؟" د کاپي فاسټ او ګپ شپ په اړه توضیحاتو سره.
• د یوري ناصر الدینوف راپور "څنګه VK د لسګونو زرو سرورونو څخه کلیک هاؤس ته ډیټا داخلوي".
• زما راپور "د VKontakte مثال په کارولو سره د مخ پر ودې پروژې جوړښت"، مګر د پراختیا له نظره ، نه هارډویر.

الیکسي اکولوویچ یو له هغو کسانو څخه دی چې د پروګرام کمیټې د یوې برخې په توګه مرسته کوي پی ایچ پی روسیه د می په 17th به په وروستي وختونو کې د PHP پراختیا کونکو لپاره ترټولو لویه پیښه شي. وګورئ چې موږ څومره ښه کمپیوټر لرو، څه سپیکرې (دوه یې د PHP اصلي وده کوي!) - داسې ښکاري چې تاسو نشئ کولی له لاسه ورکړئ که تاسو PHP ولیکئ.

سرچینه: www.habr.com