ارټیم ډینسوف ( , )
Badoo د نړۍ ترټولو لوی تاریخي سایټ دی. موږ اوس مهال په ټوله نړۍ کې شاوخوا 330 ملیون راجستر شوي کاروونکي لرو. مګر هغه څه چې نن ورځ زموږ د خبرو اترو په شرایطو کې خورا مهم دي هغه دا دي چې موږ د کاروونکو عکسونو شاوخوا 3 پیټابایټ ذخیره کوو. هره ورځ زموږ کاروونکي شاوخوا 3,5 ملیون نوي عکسونه اپلوډ کوي ، او د لوستلو بار شاوخوا دی په هره ثانیه کې 80 زره غوښتنې. دا زموږ د شالید لپاره خورا ډیر دی ، او ځینې وختونه پدې کې ستونزې شتون لري.
زه به د دې سیسټم ډیزاین په اړه وغږیږم ، کوم چې په عمومي ډول عکسونه ذخیره کوي او لیږي ، او زه به یې د پراختیا کونکي له نظره وګورم. د دې په اړه به یو لنډ سابقه وي چې دا څنګه رامینځته شوی ، چیرې چې زه به اصلي مرحلې په ګوته کړم ، مګر زه به یوازې د هغه حلونو په اړه په ډیر تفصیل سره وغږیږم چې موږ یې اوس کاروو.
اوس راځئ چې پیل وکړو.
لکه څنګه چې ما وویل، دا به یو شاتګ وي، او د دې لپاره چې له کوم ځای څخه پیل شي، راځئ چې ترټولو عام مثال واخلو.
موږ یو ګډ کار لرو، موږ اړتیا لرو چې د کاروونکي عکسونه ومنو، ذخیره او لیږو. په دې فورمه کې، دنده عمومي ده، موږ کولی شو هر څه وکاروو:
- عصري بادل ذخیره،
- یو بکس شوی حل، چې اوس هم ډیر شتون لري؛
- موږ کولی شو په خپل ډیټا مرکز کې ډیری ماشینونه تنظیم کړو او په دوی کې لوی هارډ ډرایو واچوو او عکسونه پکې ذخیره کړو.
بدو په تاریخي ډول - اوس او بیا دواړه (په هغه وخت کې چې دا یوازې په ماشومتوب کې و) - په خپلو سرورونو کې ژوند کوي، زموږ په DCs کې. له همدې امله، دا اختیار زموږ لپاره غوره و.
موږ یوازې څو ماشینونه واخیستل، دوی ته یې "عکسونه" ویل، او موږ یو کلستر ترلاسه کړ چې عکسونه ذخیره کوي. مګر داسې ښکاري چې یو څه ورک دی. د دې ټولو د کار کولو لپاره، موږ باید یو څه وټاکو چې په کوم ماشین کې به موږ کوم عکسونه ذخیره کړو. او دلته هم د امریکا د خلاصون اړتیا نشته.
موږ د کاروونکو په اړه د معلوماتو سره زموږ ذخیره کې ځینې ساحې اضافه کوو. دا به د شارډینګ کیلي وي. زموږ په قضیه کې، موږ دې ته د ځای_id نوم ورکړ، او دا ځای ID هغه ځای ته اشاره کوي چیرې چې د کاروونکي عکسونه زیرمه شوي. موږ نقشې جوړوو.
په لومړي مرحله کې ، دا حتی په لاسي ډول ترسره کیدی شي - موږ وایو چې د دې کارونکي عکس به د ورته ځای سره په ورته سرور کې ځای په ځای شي. د دې نقشې څخه مننه، موږ تل پوهیږو کله چې یو کاروونکي عکس اپلوډ کوي، چیرته یې خوندي کړي، او موږ پوهیږو چې له کوم ځای څخه یې ورکړو.
دا یو خورا کوچنی سکیم دی، مګر دا د پام وړ ګټې لري. لومړی دا چې دا ساده دی، لکه څنګه چې ما وویل، او دوهم دا چې د دې طریقې سره موږ کولی شو په ساده ډول د نوي موټرو په وړاندې کولو او په نقشه کې اضافه کولو سره په افقی ډول اندازه کړو. تاسو اړتیا نلرئ بل څه وکړئ.
د یو څه وخت لپاره زموږ لپاره همداسې وه.
دا شاوخوا 2009 وه. دوی موټرونه ورکړل، تحویل کړل ...
او په یو وخت کې موږ په دې پوهیدل پیل کړل چې دا سکیم ځینې زیانونه لري. زیانونه یې څه دي؟
تر ټولو لومړی، محدود ظرفیت شتون لري. موږ نشو کولی په یو فزیکي سرور کې څومره هارډ ډرایوونه ولګوو څومره چې موږ غواړو. او دا د وخت په تیریدو او د ډیټاسیټ وده سره یوه ځانګړې ستونزه ګرځیدلې.
او دوهم. دا د ماشینونو غیر معمولي ترتیب دی، ځکه چې دا ډول ماشینونه په ځینو نورو کلسترونو کې بیا کارول ستونزمن دي؛ دوی خورا مشخص دي، د بیلګې په توګه. دوی باید په فعالیت کې ضعیف وي، مګر په ورته وخت کې د لوی هارډ ډرایو سره.
دا ټول د 2009 لپاره وو، مګر، په اصولو کې، دا اړتیاوې لا تر اوسه پورې تړاو لري. موږ یو سابقه لرو، نو په 2009 کې هرڅه په بشپړ ډول خراب وو.
او وروستی ټکی قیمت دی.
په هغه وخت کې قیمت خورا لوړ و، او موږ اړتیا درلوده چې ځینې بدیلونه وګورو. هغوی. موږ اړتیا درلوده چې په یو څه ډول د معلوماتو مرکزونو او فزیکي سرورونو کې دواړه ځای په ښه توګه وکاروو چې دا ټول موقعیت لري. او زموږ د سیسټم انجینرانو یوه لویه مطالعه پیل کړه په کوم کې چې دوی د مختلف انتخابونو ډله بیاکتنه وکړه. دوی د کلستر شوي فایل سیسټمونو لکه PolyCeph او Luster ته هم کتل. د فعالیت ستونزې او خورا ستونزمن عملیات شتون درلود. دوی انکار وکړ. موږ هڅه وکړه چې ټول ډیټا سیټ د NFS له لارې په هر موټر کې نصب کړو ترڅو یو څه اندازه یې پورته کړو. لوستل هم خراب شوي ، موږ د مختلف پلورونکو څخه مختلف حلونه هڅه وکړه.
او په پای کې، موږ د تش په نامه د ذخیرې ساحې شبکې کارولو په اړه پریکړه وکړه.
دا لوی SHDs دي چې په ځانګړي ډول د ډیټا لوی مقدار ذخیره کولو لپاره ډیزاین شوي. دا د ډیسکونو سره المارۍ دي چې په وروستي نظری محصول ماشینونو کې ایښودل شوي. هغه. موږ د ماشینونو یو ډول حوض لرو، خورا کوچني، او دا SHDs، چې زموږ د لیږلو منطق ته شفاف دي، د بیلګې په توګه. زموږ د نګینکس یا بل چا لپاره چې د دې عکسونو غوښتنې خدمت وکړي.
دا پریکړه ښکاره ګټې درلودې. دا SHD دی. دا د عکسونو ذخیره کولو هدف دی. دا په ساده ډول د هارډ ډرایو سره د ماشینونو تجهیز کولو په پرتله ارزانه کار کوي.
دوهم پلس.
دا دا دی چې ظرفیت خورا لوی شوی دی، د بیلګې په توګه. موږ کولی شو په خورا کوچني حجم کې خورا ډیر ذخیره ځای په ځای کړو.
مګر دلته نیمګړتیاوې هم وې چې په چټکۍ سره راڅرګندې شوې. لکه څنګه چې په دې سیسټم کې د کاروونکو شمیر او بار وده وکړه، د فعالیت ستونزې را منځته شوې. او دلته ستونزه خورا څرګنده ده - هر ډول SHD په کوچني حجم کې د ډیری عکسونو ذخیره کولو لپاره ډیزاین شوی ، د یوې قاعدې په توګه ، د ژور لوستلو سره مخ کیږي. دا په حقیقت کې د هر بادل ذخیره یا بل څه لپاره ریښتیا ده. اوس موږ یو مثالی ذخیره نلرو چې په غیر محدود ډول د توزیع وړ وي ، تاسو کولی شئ پدې کې هرڅه ډک کړئ ، او دا به لوستل خورا ښه برداشت کړي. په ځانګړي توګه عادي لوستل.
لکه څنګه چې زموږ د عکسونو قضیه ده ، ځکه چې عکسونه په متناسب ډول غوښتنه کیږي ، او دا به د دوی فعالیت خورا اغیزه وکړي.
حتی د نن ورځې ارقامو سره سم ، که موږ په ماشین کې د عکسونو لپاره له 500 RPS څخه ډیر چیرې ترلاسه کړو چې ذخیره ورسره وصل وي ، ستونزې لا دمخه پیل کیږي. او دا زموږ لپاره خورا خراب و ، ځکه چې د کاروونکو شمیر مخ په ډیریدو دی ، شیان یوازې خرابیږي. دا باید په یو ډول اصلاح شي.
د اصلاح کولو لپاره ، موږ په هغه وخت کې پریکړه وکړه ، په څرګنده توګه ، د بار پروفایل ته وګورو - څه ، په عموم کې ، پیښیږي ، څه ته اړتیا لیدل کیږي.
او دلته هرڅه زموږ په لاسونو کې لوبیږي.
ما دمخه په لومړي سلایډ کې وویل: موږ په هره ثانیه کې د 80 زره لوستلو غوښتنې لرو چې هره ورځ یوازې 3,5 ملیون اپلوډونه لري. يعنې دا د دريو حکمونو د اندازې توپير دی. دا څرګنده ده چې لوستل باید اصلاح شي او دا په عملي ډول روښانه ده چې څنګه.
یو بل کوچنی ټکی هم شته. د خدماتو ځانګړتیاوې داسې دي چې یو شخص راجستر کوي، عکس اپلوډ کوي، بیا په فعاله توګه نورو خلکو ته ګوري، لکه د دوی په څیر، او په فعاله توګه نورو خلکو ته ښودل کیږي. بیا هغه یو ملګری پیدا کوي یا ملګری نه موندل کیږي، دا پدې پورې اړه لري چې دا څنګه وګرځي، او د یو څه مودې لپاره د خدمت کارول ودروي. په دې وخت کې، کله چې هغه کاروي، د هغه عکسونه خورا ګرم دي - دوی په تقاضا کې دي، ډیری خلک یې ګوري. هرڅومره ژر چې هغه دا کار ودروي ، ډیر ژر هغه د نورو خلکو سره د هغه ډیر افشا کیدو څخه لرې کیږي لکه څنګه چې دمخه یې درلود ، او د هغه عکسونه تقریبا هیڅکله غوښتنه نه کیږي.
هغوی. موږ یو ډیر کوچنی ګرم ډیټاسیټ لرو. مګر په ورته وخت کې د هغه لپاره ډیری غوښتنې شتون لري. او دلته یو بشپړ څرګند حل د کیچ اضافه کول دي.
د LRU سره کیچ به زموږ ټولې ستونزې حل کړي. موږ څه کوو؟
موږ د ذخیره کولو سره زموږ د لوی کلستر مخې ته یو بل نسبتا کوچنی اضافه کوو ، کوم چې د فوټوکیچ په نوم یادیږي. دا په اصل کې یوازې د کیشینګ پراکسي ده.
دا څنګه له دننه څخه کار کوي؟ دلته زموږ کارن دی، دلته ذخیره ده. هر څه د پخوا په شان دي. موږ په منځ کې څه اضافه کوو؟
دا یوازې یو ماشین دی چې د فزیکي محلي ډیسک سره دی، کوم چې چټک دی. دا د SSD سره دی، د بیلګې په توګه. او په دې ډیسک کې یو ډول محلي زیرمه ساتل کیږي.
دا څه ډول ښکاري؟ کارونکي د عکس لپاره غوښتنه لیږي. NGINX لومړی په محلي زیرمه کې لټوي. که نه، نو په ساده ډول زموږ ذخیرې ته پراکسي_پاس کړئ، له هغه ځایه عکس ډاونلوډ کړئ او کارونکي ته یې ورکړئ.
مګر دا خورا مجرد دی او دا روښانه نده چې دننه څه پیښیږي. دا د دې په څیر یو څه کار کوي.
زیرمه په منطقي توګه په دریو پرتونو ویشل شوې ده. کله چې زه "درې پرتونه" وایم، دا پدې معنی ندي چې یو ډول پیچلي سیسټم شتون لري. نه، دا په مشروط ډول د فایل سیسټم کې یوازې درې لارښودونه دي:
- دا یو بفر دی چیرې چې عکسونه یوازې د پراکسي ګو څخه ډاونلوډ شوي.
- دا یو ګرم زیرمه ده چې اوس مهال په فعاله توګه غوښتل شوي عکسونه ذخیره کوي.
- او یو سړه زیرمه ، چیرې چې عکسونه په تدریجي ډول د ګرمې زیرمې څخه ایستل کیږي کله چې دوی ته لږ غوښتنې راشي.
د دې کار کولو لپاره ، موږ اړتیا لرو په یو ډول دا زیرمه اداره کړو ، موږ اړتیا لرو په دې کې عکسونه بیا تنظیم کړو ، او داسې نور. دا هم یو ډیر ابتدايي بهیر دی.
نګینکس په ساده ډول د هرې غوښتنې لپاره RAMDisk access.log ته لیکي ، په کوم کې چې دا د عکس لاره په ګوته کوي چې دا مهال یې خدمت کړی دی (نسباتي لاره ، البته) ، او کوم تقسیم چې دا خدمت شوی و. هغوی. دا ممکن "عکس 1" ووایی او بیا یا بفر، یا ګرم کیچ، یا سړه کیچ، یا پراکسي.
په دې پورې اړه لري، موږ باید یو څه پریکړه وکړو چې د عکس سره څه وکړو.
موږ په هر ماشین کې یو کوچنی ډیمون لرو چې په دوامداره توګه دا لاګ لولي او په حافظه کې د ځانګړي عکسونو کارولو احصایې ذخیره کوي.
هغه په ساده ډول هلته راټولوي، شمېرونکي ساتي او په وخت سره لاندې کارونه کوي. هغه په فعاله توګه غوښتل شوي عکسونه حرکت کوي، د کوم لپاره چې ډیری غوښتنې شتون لري، ګرمې زیرمې ته، هرچیرې چې وي.
هغه عکسونه چې په ندرت سره غوښتل شوي او لږ ځله غوښتل شوي وي په تدریجي ډول د ګرمې زیرمې څخه ساړه ته ایستل کیږي.
او کله چې موږ په زیرمه کې ځای له لاسه ورکړو ، نو موږ په ساده ډول د سړې زیرمې څخه په بې توپیره هرڅه حذف کول پیل کوو. او په لاره کې، دا ښه کار کوي.
د دې لپاره چې عکس سمدلاسه خوندي شي کله چې بفر ته پراکسي کول ، موږ د پراکسي_سټور لارښود کاروو او بفر هم یو RAMDisk دی ، د مثال په توګه. د کارونکي لپاره دا خورا ګړندي کار کوي. دا پخپله د کیشینګ سرور داخلي اندیښمن دي.
پاتې پوښتنه دا ده چې څنګه په دې سرورونو کې غوښتنې توزیع کړئ.
راځئ چې ووایو دلته د شل ذخیره کولو ماشینونو او درې کیچنګ سرورونو کلستر شتون لري (دا څنګه پیښ شوي).
موږ اړتیا لرو چې یو څه وټاکو چې کومې غوښتنې د کوم عکسونو لپاره دي او چیرې یې ځای په ځای کړي.
تر ټولو عام انتخاب Round Robin دی. یا دا په ناڅاپي ډول ترسره کوئ؟
دا په ښکاره ډول یو شمیر زیانونه لري ځکه چې موږ به په داسې حالت کې کیچ په خورا غیر موثر ډول وکاروو. غوښتنې به په ځینو تصادفي ماشینونو کې ځای په ځای شي: دلته دا زیرمه شوې ، مګر په راتلونکي کې دا نور شتون نلري. او که دا ټول کار وکړي، دا به خورا بد وي. حتی په کلستر کې د لږ شمیر ماشینونو سره.
موږ اړتیا لرو په یو ډول په ناڅرګند ډول وټاکو چې کوم سرور ته اړتیا لري چې کومه غوښتنه وکړي.
یوه عادي لاره شتون لري. موږ له یو آر ایل یا هش څخه زموږ د شارډینګ کیلي څخه هش اخلو، کوم چې په URL کې دی، او د سرورونو په شمیر سره یې ویشو. کار به وکړي؟ به.
هغوی. موږ 2٪ غوښتنه لرو، د بیلګې په توګه، د ځینې "example_url" لپاره دا به تل په سرور کې د شاخص "XNUMX" سره راشي، او زیرمه به په دوامداره توګه د امکان تر حده غوره له منځه یوړل شي.
مګر په داسې سکیم کې د بیا تنظیم کولو سره ستونزه شتون لري. بیاځل کول - زما مطلب د سرورونو شمیر بدلول.
راځئ فرض کړو چې زموږ د کیشینګ کلستر نور نشي کولی مقابله وکړي او موږ پریکړه کوو چې بل ماشین اضافه کړو.
راځئ چې اضافه کړو.
اوس هر څه په دریو نه، بلکې په څلورو ویشل کیږي. په دې توګه، نږدې ټول هغه کلیدونه چې موږ یې درلودل، نږدې ټول URLs اوس په نورو سرورونو کې ژوند کوي. ټوله زیرمه په ساده ډول د یوې شیبې لپاره باطله شوه. ټولې غوښتنې زموږ د ذخیره کولو کلستر کې راوتلې، دا ناروغه شوه، د خدماتو ناکامي او ناخوښه کاروونکي. زه نه غواړم دا وکړم.
دا اختیار موږ ته هم مناسب نه دی.
هغه. څه باید وکړو؟ موږ باید په یو ډول د کیچ مؤثره کار واخلو، ورته غوښتنه په ورته سرور کې بار بار ځای پر ځای کړو، مګر د بیا ځای پرځای کولو په وړاندې مقاومت وکړو. او داسې حل شتون لري، دا دومره پیچلې نه ده. دا د دوامداره هشنګ په نوم یادیږي.
دا څه ښکاري؟
موږ د شارډینګ کیلي څخه یو څه فنکشن اخلو او ټول ارزښتونه یې په دایره کې خپروو. هغوی. په 0 نقطه کې، لږترلږه او اعظمي ارزښتونه سره یو ځای کیږي. بیا، موږ خپل ټول سرورونه په ورته دایره کې نږدې په دې ډول ځای په ځای کوو:
هر سرور د یوې نقطې لخوا تعریف شوی، او هغه سکتور چې د ساعت په څیر ورته ځي، د دې کوربه لخوا خدمت کیږي. کله چې غوښتنې موږ ته راشي، موږ سمدلاسه ګورو چې د مثال په توګه، د A غوښتنه وکړئ - دا هلته یو هش لري - او دا د سرور 2 لخوا خدمت کیږي. غوښتنه B - د سرور 3 لخوا. او داسې نور.
په دې حالت کې د بیا تبادلې پرمهال څه پیښیږي؟
موږ د پخوا په څیر ټوله زیرمه باطله نه کوو، او ټولې کیلي نه بدلوو، مګر موږ هر سکتور لږ فاصله لیږدوو ترڅو په نسبي توګه خبرې وکړو، زموږ شپږم سرور، چې موږ یې اضافه کول غواړو، په وړیا ځای کې فټ شي، او موږ یې هلته اضافه کوو.
البته، په داسې حالت کې کلیدونه هم بهر حرکت کوي. مګر دوی د پخوا په پرتله خورا کمزوري حرکت کوي. او موږ ګورو چې زموږ لومړۍ دوه کیلي د دوی په سرورونو کې پاتې دي، او د کیچ کولو سرور یوازې د وروستي کیلي لپاره بدل شوی. دا په خورا مؤثره توګه کار کوي، او که تاسو په تدریجي ډول نوي کوربه اضافه کړئ، نو دلته کومه لویه ستونزه نشته. تاسو په یو وخت کې یو څه اضافه کړئ او اضافه کړئ، تر هغه پورې انتظار وکړئ چې کیچ بیا ډک شي، او هرڅه ښه کار کوي.
یوازینۍ پوښتنه د انکار سره پاتې ده. راځئ چې فرض کړو چې یو ډول موټر له نظم څخه بهر دی.
او موږ به واقعیا پدې وخت کې دا نقشه بیا رامینځته نه کړو ، د کیچ برخه باطله کړو ، او داسې نور ، که د مثال په توګه ، ماشین ریبوټ شوی و ، او موږ اړتیا لرو په یو ډول د خدماتو غوښتنې ته اړتیا ولرو. موږ په ساده ډول په هر سایټ کې د بیک اپ عکس کیچ ساتو ، کوم چې د هر هغه ماشین لپاره د بدیل په توګه کار کوي چې اوس مهال ښکته دی. او که ناڅاپه زموږ یو سرور شتون ونلري، ترافیک هلته ځي. په طبیعي توګه، موږ هلته هیڅ زیرمه نلرو، د بیلګې په توګه. دا سړه ده، مګر لږترلږه د کاروونکي غوښتنې پروسس کیږي. که دا یو لنډ وقف وي، نو موږ دا په بشپړ ډول په آرامۍ سره تجربه کوو. په ذخیره کې ډیر بار شتون لري. که دا وقفه اوږده وي، نو موږ دمخه پریکړه کولی شو - دا سرور له نقشې څخه لرې کړو یا نه، یا شاید دا د بل سره بدل کړو.
دا د کیشینګ سیسټم په اړه دی. راځئ چې پایلې وګورو.
داسې ښکاري چې دلته هیڅ پیچلي ندي. مګر د کیچ اداره کولو دې میتود موږ ته د 98٪ په اړه د چال نرخ راکړ. هغوی. په هره ثانیه کې د دې 80 زره غوښتنو څخه، یوازې 1600 ذخیره کولو ته رسیږي، او دا یو بشپړ نورمال بار دی، دوی په آرامۍ سره دا برداشت کوي، موږ تل ذخیره لرو.
موږ دا سرورونه زموږ په دریو DC کې ځای په ځای کړل، او د شتون درې ټکي مو ترلاسه کړل - پراګ، میامي او هانګ کانګ.
هغه. دوی لږ یا لږ په محلي توګه زموږ هر هدف بازار ته موقعیت لري.
او د یو ښه بونس په توګه، موږ دا کیشینګ پراکسي ترلاسه کړه، په کوم کې چې CPU په حقیقت کې بې کاره دی، ځکه چې دا د مینځپانګې خدمت کولو لپاره دومره اړتیا نلري. او هلته، د NGINX+ Lua په کارولو سره، موږ ډیری ګټور منطق پلي کړ.
د مثال په توګه، موږ کولی شو د ویبپ یا پرمختللی jpeg سره تجربه وکړو (دا اغیزمن عصري بڼه دي)، وګورئ چې دا څنګه ټرافیک اغیزه کوي، ځینې پریکړې وکړي، د ځینو هیوادونو لپاره یې فعال کړي، او داسې نور. په الوتنه کې متحرک عکسونه بدل کړئ یا کراپ کړئ.
دا یو ښه کارونې قضیه ده کله چې تاسو د مثال په توګه یو ګرځنده اپلیکیشن لرئ چې عکسونه ښیې، او د ګرځنده اپلیکیشن نه غواړي د پیرودونکي CPU د لوی عکس غوښتنه کولو کې ضایع کړي او بیا یې د یوې ټاکلې اندازې له سره تنظیم کړي ترڅو دا یې په نښه کړي. ننداره. موږ کولی شو په ساده ډول په UPort مشروط URL کې ځینې پیرامیټونه په متحرک ډول مشخص کړو، او د عکس زیرمه به پخپله عکس له سره اندازه کړي. د یوې قاعدې په توګه، دا به هغه اندازه وټاکي چې موږ په فزیکي توګه په ډیسک کې لرو، څومره چې ممکنه وي غوښتل شوي ته نږدې وي، او په ځانګړو همغږۍ کې یې وپلورئ.
په هرصورت ، موږ د لوړ بار سیسټمونو پراختیا کونکو کنفرانس کې د تیرو پنځو کلونو ویډیو ریکارډونه په عامه توګه چمتو کړي دي . وګورئ، زده کړئ، شریک کړئ او ګډون وکړئ .
موږ کولی شو هلته د محصول ډیری منطق اضافه کړو. د مثال په توګه، موږ کولی شو د URL پیرامیټونو په کارولو سره مختلف واټر مارکونه اضافه کړو، موږ کولی شو عکسونه تور، تور یا pixelate کړو. دا هغه وخت دی چې موږ غواړو د یو کس عکس وښایه، مګر موږ نه غواړو د هغه مخ ښکاره کړو، دا ښه کار کوي، دا ټول دلته پلي کیږي.
موږ څه ترلاسه کړل؟ موږ د شتون درې ټکي ترلاسه کړل ، د ښه چال نرخ ، او په ورته وخت کې موږ پدې ماشینونو کې بې کاره CPU نلرو. هغه اوس، البته، د پخوا په پرتله ډیر مهم شوی دی. موږ اړتیا لرو ځان ته قوي موټرې ورکړو، مګر دا د دې ارزښت لري.
دا د عکسونو بیرته راستنیدو اندیښنه لري. دلته هرڅه خورا روښانه او څرګند دي. زه فکر کوم چې ما امریکا نه ده موندلې، نږدې هر CDN دا کار کوي.
او، ډیری احتمال، یو پیچلي اوریدونکی شاید پوښتنه ولري: ولې یوازې هر څه CDN ته نه بدلوي؟ دا به ورته وي؛ ټول عصري CDN کولی شي دا کار وکړي. او یو شمیر لاملونه شتون لري.
لومړی عکسونه دي.
دا زموږ د زیربنا یو له مهمو ټکو څخه دی، او موږ د امکان تر حده ډیر کنټرول ته اړتیا لرو. که دا د دریمې ډلې پلورونکي څخه یو ډول حل وي ، او تاسو پدې باندې هیڅ ځواک نلرئ ، نو دا به ستاسو لپاره خورا ستونزمن وي چې ورسره ژوند وکړئ کله چې تاسو لوی ډیټاسیټ ولرئ ، او کله چې تاسو خورا لوی جریان ولرئ. د کاروونکي غوښتنې.
اجازه راکړئ تاسو ته یو مثال درکړم. اوس، زموږ د زیربنا سره، موږ کولی شو، د بیلګې په توګه، د ځینو ستونزو یا د ځمکې لاندې ټکانونو په صورت کې، ماشین ته لاړ شو او هلته په نسبي توګه خبرې وکړو. موږ کولی شو د ځینې میټریکونو ټولګه اضافه کړو چې موږ ورته اړتیا لرو، موږ کولی شو یو څه تجربه کړو، وګورو چې دا څنګه په ګرافونو اغیزه کوي، او داسې نور. اوس د دې کیچنګ کلستر په اړه ډیری احصایې راټولیږي. او موږ وخت په وخت دې ته ګورو او د ځینې بې نظمیو په سپړلو کې اوږد وخت تیروو. که دا د CDN اړخ کې و، نو کنټرول به یې خورا ستونزمن وي. یا، د مثال په توګه، که یو ډول حادثه رامنځته شي، موږ پوهیږو چې څه پیښ شوي، موږ پوهیږو چې څنګه ورسره ژوند وکړو او څنګه یې له منځه یوسو. دا لومړۍ پایله ده.
دویمه پایله هم تاریخي ده، ځکه چې سیسټم د اوږدې مودې لپاره وده کوي، او په مختلفو مرحلو کې ډیری مختلف سوداګریزې اړتیاوې وې، او دوی تل د CDN مفهوم سره سمون نلري.
او هغه ټکی چې د تیر څخه تعقیب کیږي
دا ځکه چې د عکس په کیچونو کې موږ ډیری ځانګړي منطق لرو ، کوم چې تل د غوښتنې سره اضافه کیدی نشي. دا امکان نلري چې کوم CDN به ستاسو په غوښتنه تاسو ته ځینې دودیز شیان اضافه کړي. د مثال په توګه، د URLs کوډ کول که تاسو نه غواړئ چې پیرودونکي د یو څه بدلولو توان ولري. ایا تاسو غواړئ په سرور کې URL بدل کړئ او کوډ یې کړئ، او بیا دلته ځینې متحرک پیرامیټونه واستوئ.
دا کومه پایله وړاندیز کوي؟ زموږ په قضیه کې، CDN خورا ښه بدیل ندی.
او ستاسو په قضیه کې، که تاسو کوم ځانګړي سوداګریزې اړتیاوې لرئ، نو تاسو کولی شئ په اسانۍ سره هغه څه پلي کړئ چې ما تاسو ته ښودلي. او دا به د ورته بار پروفایل سره سم کار وکړي.
مګر که تاسو یو ډول عمومي حل لرئ، او دنده خورا مشخص نه وي، تاسو کولی شئ په بشپړ ډول په خوندي ډول CDN واخلئ. یا که وخت او سرچینې تاسو ته د کنټرول په پرتله خورا مهم دي.
او عصري CDNs نږدې هرڅه لري چې ما تاسو ته اوس په اړه وویل. د جمع یا منفي ځینې ځانګړتیاو استثنا سره.
دا د عکسونو ورکولو په اړه دی.
راځئ چې اوس زموږ په شاتګ کې یو څه مخکې لاړ شو او د ذخیره کولو په اړه وغږیږو.
2013 تیر شو.
د کیشینګ سرورونه اضافه شوي، د فعالیت ستونزې لرې شوې. هر څه سم دي. ډیټاسیټ وده کوي. تر 2013 پورې، موږ شاوخوا 80 سرورونه د ذخیره کولو سره وصل درلودل، او په هر DC کې شاوخوا 40 کیشینګ. دا په هر DC کې د 560 ټیرابایټ ډیټا دی، i.e. په مجموع کې د یو پیټابایټ په اړه.
او د ډیټاسیټ وده سره ، عملیاتي لګښتونه د پام وړ لوړیدل پیل کړل. دا څه مانا؟
پدې ډیاګرام کې چې رسم شوی - د SAN سره ، د ماشینونو او کیچونو سره چې ورسره وصل دی - د ناکامۍ ډیری ټکي شتون لري. که موږ دمخه دمخه د کیچ کولو سرورونو ناکامۍ سره معامله کړې وي ، هرڅه لږ یا لږ د وړاندوینې وړ او د پوهیدو وړ و ، مګر د ذخیره کولو اړخ کې هرڅه خورا خراب وو.
لومړی، د ذخیره کولو ساحې شبکه (SAN) پخپله، کوم چې ناکام کیدی شي.
دوهم ، دا د پای ماشینونو سره د آپټیکس له لارې وصل دی. ممکن د آپټیکل کارتونو او سپارک پلګونو سره ستونزې وي.
البته، د دوی په څیر ډیری شتون نلري لکه د SAN سره، مګر، سره له دې، دا د ناکامۍ ټکي هم دي.
بل پخپله ماشین دی، کوم چې د ذخیره کولو سره وصل دی. دا هم ناکامه کیدی شي.
په مجموع کې، موږ د ناکامۍ درې ټکي لرو.
سربیره پردې ، د ناکامۍ ټکو سربیره ، پخپله د ذخیره کولو درانه ساتنه شتون لري.
دا یو پیچلی څو اجزاو سیسټم دی، او د سیسټم انجنیران کولی شي سخت وخت ولري چې ورسره کار وکړي.
او وروستی، خورا مهم ټکی. که چیرې په دې دریو ټکو کې ناکامي رامینځته شي ، نو موږ د کارونکي ډیټا له لاسه ورکولو غیر صفر چانس لرو ځکه چې د فایل سیسټم ممکن خراب شي.
راځئ چې ووایو زموږ د فایل سیسټم مات شوی. لومړی، د هغې بیا رغونه ډیر وخت نیسي - دا کولی شي د ډیرو معلوماتو سره یوه اونۍ وخت ونیسي. او دوهم ، په پای کې به موږ ډیری احتمال د نه پوهیدو وړ فایلونو سره پای ته ورسوو چې اړتیا به یې په یو ډول د کارونکي عکسونو سره یوځای شي. او موږ د معلوماتو له لاسه ورکولو خطر لرو. خطر خورا لوړ دی. او هرڅومره چې دا ډول حالتونه پیښیږي ، او په دې ټول سلسله کې ډیرې ستونزې رامینځته کیږي ، نو دا خطر خورا لوړ دی.
په دې اړه باید یو څه وشي. او موږ پریکړه وکړه چې موږ یوازې د معلوماتو بیک اپ ته اړتیا لرو. دا واقعیا یو څرګند حل او ښه دی. موږ څه کړي دي؟
دا هغه څه دي چې زموږ سرور داسې ښکاري کله چې دا دمخه د ذخیره کولو سره وصل شوی و. دا یوه اصلي برخه ده ، دا یوازې د بلاک وسیله ده چې واقعیا د آپټیکس له لارې د ریموټ ذخیره کولو لپاره ماونټ نمایش کوي.
موږ یوازې دویمه برخه اضافه کړه.
موږ د دې تر څنګ دوهم ذخیره کیښوده (له نېکه مرغه، دا د پیسو په شرایطو کې دومره ګران نه دی)، او دا یې د بیک اپ برخې په نوم یاد کړ. دا د آپټیکس له لارې هم وصل دی او په ورته ماشین کې موقعیت لري. مګر موږ اړتیا لرو چې یو څه د دوی ترمینځ ډاټا همغږي کړو.
دلته موږ په ساده ډول نږدې یو غیر متناسب کتار جوړوو.
هغه ډېره بوخته نه ده. موږ پوهیږو چې موږ کافي ریکارډونه نلرو. کتار په MySQL کې یوازې یو میز دی چې پکې "تاسو د دې عکس بیک اپ کولو ته اړتیا لرئ" په څیر لیکې لیکل شوي. د هر ډول بدلون یا اپلوډ سره، موږ د غیر متناسب یا یوازې یو ډول شالید کارکونکي په کارولو سره د اصلي برخې څخه بیک اپ ته کاپي کوو.
او په دې توګه موږ تل دوه ثابتې برخې لرو. حتی که د دې سیسټم یوه برخه ناکامه شي، موږ کولی شو تل د بیک اپ سره اصلي برخه بدل کړو، او هرڅه به کار ته دوام ورکړي.
مګر د دې له امله ، د لوستلو بار خورا ډیریږي ، ځکه چې ... د پیرودونکو سربیره چې د اصلي برخې څخه لوستل کیږي، ځکه چې دوی لومړی هلته عکس ګوري (دا هلته وروستی دی)، او بیا یې په بیک اپ کې وګورئ، که دوی دا ونه موندل (مګر NGINX یوازې دا کوي) زموږ سیسټم هم یو پلس بیک اپ دی چې اوس د اصلي برخې څخه لوستل کیږي. دا نده چې دا یو خنډ و ، مګر زه نه غواړم بار ډیر کړم ، په لازمي ډول ، د ورته په څیر.
او موږ دریم ډیسک اضافه کړ، کوم چې یو کوچنی SSD دی، او دا یو بفر نومیږي.
دا اوس څنګه کار کوي.
کارونکي بفر ته عکس اپلوډ کوي ، بیا یوه پیښه په کتار کې اچول کیږي چې دا په ګوته کوي چې دا باید په دوه برخو کې کاپي شي. دا کاپي شوی، او عکس د یو څه وخت لپاره په بفر کې ژوند کوي (ووایه، یوه ورځ)، او یوازې بیا له هغه ځایه پاکیږي. دا د کاروونکي تجربه خورا ښه کوي، ځکه چې کاروونکي عکس اپلوډ کوي، د یوې قاعدې په توګه، غوښتنې سمدلاسه تعقیب پیل کوي، یا هغه پخپله پاڼه تازه کړه او تازه یې کړه. مګر دا ټول په هغه غوښتنلیک پورې اړه لري چې اپلوډ کوي.
یا، د بیلګې په توګه، نور خلک چې هغه یې خپل ځان ښودل پیل کړل سمدلاسه د دې عکس وروسته غوښتنې واستول. دا لا تر اوسه په کیچ کې نه دی؛ لومړۍ غوښتنه په چټکۍ سره واقع کیږي. اساسا د عکس کیچ څخه ورته ورته. ورو ذخیره په دې کې دخیل نه ده. او کله چې یوه ورځ وروسته دا پاک شي ، دا دمخه یا زموږ د کیشینګ پرت کې زیرمه شوی ، یا ، ډیری احتمال ، هیڅوک ورته اړتیا نلري. هغوی. دلته د کارونکي تجربه د داسې ساده لاسوهنو له امله خورا ښه وده کړې.
ښه، او تر ټولو مهم: موږ د معلوماتو له لاسه ورکول بند کړل.
راځئ یوازې ووایو چې موږ ودریږو په بالقوه توګه ډاټا له لاسه ورکړئ، ځکه چې موږ واقعیا له لاسه نه ورکوو. مګر خطر شتون درلود. موږ ګورو چې دا حل البته ښه دی، مګر دا د دې پر ځای چې په بشپړه توګه حل شي، د ستونزې نښې نښانې له منځه یوسي. او ځینې ستونزې دلته پاتې دي.
لومړی، دا پخپله د فزیکي کوربه په بڼه کې د ناکامۍ نقطه ده چې دا ټول ماشینونه پرمخ ځي؛ هغه نه دی تللی.
دوهم، د SANs سره لاهم ستونزې شتون لري، د دوی سخت ساتنه او نور پاتې دي. دا نه و چې دا یو مهم فکتور و، مګر ما غوښتل هڅه وکړم چې یو څه پرته له دې ژوند وکړم.
او موږ دریمه نسخه جوړه کړه (په حقیقت کې، دویم په حقیقت کې) - د ریزرویشن نسخه. دا څه ډول ښکاري؟
دا هغه څه دي -
زموږ اصلي ستونزې د دې حقیقت سره دي چې دا یو فزیکي کوربه دی.
لومړی، موږ SANs لرې کوو ځکه چې موږ غواړو تجربه وکړو، موږ غواړو یوازې محلي هارډ ډرایو هڅه وکړو.
دا لا دمخه 2014-2015 دی، او په دې وخت کې د ډیسکونو وضعیت او په یوه کوربه کې د دوی ظرفیت خورا ښه شوی. موږ پریکړه وکړه چې ولې دا هڅه نه کوي.
او بیا موږ په ساده ډول زموږ د بیک اپ برخه اخلو او په فزیکي توګه یې جلا ماشین ته لیږدوو.
په دې توګه، موږ دا انځور ترلاسه کوو. موږ دوه موټرې لرو چې ورته ډیټاسیټونه ذخیره کوي. دوی یو بل په بشپړ ډول بیک اپ کوي او په ورته MySQL کې د غیر متناسب کتار له لارې په شبکه کې ډیټا همغږي کوي.
ولې دا ښه کار کوي ځکه چې موږ لږ ریکارډونه لرو. هغوی. که لیکل د لوستلو سره مقایسه شوي وای، شاید موږ به یو ډول شبکه او ستونزې درلودې. لږ لیکل شتون لري، ډیر لوستل - دا طریقه ښه کار کوي، د بیلګې په توګه. موږ په ندرت سره د دې دوه سرورونو ترمینځ عکسونه کاپي کوو.
دا څنګه کار کوي، که تاسو په تفصیل سره لږ څه وګورئ.
پورته کول. بیلانسر په ساده ډول د یوې جوړې سره تصادفي کوربه غوره کوي او هغې ته یې اپلوډ کوي. په ورته وخت کې، هغه په طبیعي ډول روغتیایی معاینات کوي او ډاډ ترلاسه کوي چې موټر نه راوتلی. هغوی. هغه یوازې یو ژوندی سرور ته عکسونه اپلوډ کوي، او بیا د غیر متناسب کتار له لارې دا ټول د هغه ګاونډی ته کاپي شوي. د اپلوډ سره هرڅه خورا ساده دي.
کار یو څه ډیر ستونزمن دی.
لوا دلته زموږ سره مرسته وکړه، ځکه چې دا ستونزمن وي چې په وینیلا NGINX کې داسې منطق جوړ کړي. موږ لومړی لومړی سرور ته غوښتنه کوو، وګورئ چې عکس شتون لري، ځکه چې احتمالا دا پورته کیدی شي، د بیلګې په توګه، ګاونډی ته، مګر تر اوسه دلته نه دی راغلی. که عکس شتون ولري، دا ښه دی. موږ دا سمدلاسه پیرودونکي ته ورکوو او احتمالا یې زیرمه کوو.
که دا شتون ونلري، موږ په ساده ډول خپل ګاونډي ته غوښتنه کوو او له هغه ځایه یې د ترلاسه کولو تضمین کوو.
هغه. یوځل بیا موږ کولی شو ووایو: ممکن د فعالیت سره ستونزې شتون ولري ، ځکه چې دوامداره سفرونه شتون لري - عکس اپلوډ شوی و ، دا دلته ندی ، موږ د یوې پرځای دوه غوښتنې کوو ، دا باید ورو کار وکړي.
زموږ په وضعیت کې، دا په ورو ورو کار نه کوي.
موږ پدې سیسټم کې د میټریکونو ډله راټولوو، او د داسې میکانیزم مشروط سمارټ نرخ شاوخوا 95٪ دی. هغوی. د دې بیک اپ وقفه کوچنۍ ده، او د دې له امله موږ تقریبا تضمین یو، وروسته له دې چې عکس اپلوډ شو، موږ به دا لومړی ځل واخلو او دوه ځله به هیڅ ځای ته لاړ نه شو.
نو موږ نور څه ترلاسه کړي چې واقعیا ښه دي؟
پخوا، موږ د اصلي بیک اپ ویش درلود، او موږ له دوی څخه په ترتیب سره لوستل. هغوی. موږ تل لومړی په اصلي کې لټون کوو، او بیا په بیک اپ کې. دا یو حرکت و.
اوس موږ په یو وخت کې د دوه ماشینونو لوستلو څخه کار اخلو. موږ د رانډ رابین په کارولو سره غوښتنې توزیع کوو. په لږو فیصدو قضیو کې موږ دوه غوښتنې کوو. مګر په ټولیز ډول، موږ اوس د پخوا په پرتله دوه چنده د لوستلو ذخیره لرو. او بار دواړه د لیږلو ماشینونو او مستقیم د ذخیره کولو ماشینونو کې خورا کم شوی و ، کوم چې موږ هم هغه وخت درلود.
لکه څنګه چې د خطا زغم. په حقیقت کې، دا هغه څه دي چې موږ یې په عمده توګه جګړه کوله. د خطا زغم سره، دلته هرڅه ښه وګرځیدل.
یو موټر خرابیږي.
هیڅ ستونزه! د سیسټم انجنیر ممکن حتی د شپې ویښ نشي، هغه به تر سهار پورې انتظار وکړي، هیڅ بد به نه وي.
که حتی که دا ماشین ناکام شي، کتار له ترتیب څخه بهر وي، هیڅ ستونزه هم شتون نلري، لاګ به په ساده ډول لومړی په ژوندی ماشین کې راټول شي، بیا به په کتار کې اضافه شي، او بیا به موټر ته لاړ شي. یو څه وخت وروسته عملیات پیل کړئ.
د ساتنې سره ورته شی. موږ په ساده ډول یو ماشین بندوو ، په لاسي ډول یې له ټولو حوضونو څخه وباسو ، دا د ترافیک ترلاسه کول ودروي ، موږ یو ډول ساتنه کوو ، موږ یو څه ترمیم کوو ، بیا یې خدمت ته راستون کوو ، او دا بیک اپ خورا ګړندی نیسي. هغوی. هره ورځ، د یو موټر د بند وخت په څو دقیقو کې تیریږي. دا واقعیا خورا لږ دی. د غلطۍ زغملو سره، زه بیا وایم، دلته هرڅه ښه دي.
د دې بې ځایه کیدو سکیم څخه کومې پایلې ترلاسه کیدی شي؟
موږ د خطا زغم ترلاسه کړ.
د کارولو لپاره اسانه. څرنګه چې ماشینونه محلي هارډ ډرایو لري، دا د عملیاتي نقطه نظر څخه د انجنیرانو لپاره خورا اسانه دی چې ورسره کار کوي.
موږ د دوه ځله لوستلو تادیه ترلاسه کړه.
دا د غلطۍ زغم سربیره خورا ښه بونس دی.
خو ستونزې هم شته. اوس موږ د دې اړوند ځینې ځانګړتیاو خورا پیچلي پرمختګ لرو، ځکه چې سیسټم په پای کې 100٪ ثابت شوی.
موږ باید ووایو، د شالید په کوم کار کې، په دوامداره توګه فکر وکړئ: "موږ اوس په کوم سرور روان یو؟"، "ایا واقعیا دلته اوسنی عکس شتون لري؟" etc دا، البته، ټول پوښل شوي، او د پروګرام کونکي لپاره چې د سوداګرۍ منطق لیکي، دا شفاف دی. مګر، سره له دې، دا لوی پیچلی طبقه ښکاره شوه. مګر موږ چمتو یو چې دا د هغه نعمتونو په بدل کې چې موږ یې له دې څخه ترلاسه کړي یو.
او دلته بیا یو څه شخړه رامنځ ته کیږي.
ما په پیل کې وویل چې په محلي هارډ ډرایو کې د هرڅه ذخیره کول بد دي. او اوس زه وایم چې موږ دا خوښ کړ.
هو، واقعا، د وخت په تیریدو سره وضعیت ډیر بدل شوی، او اوس دا طریقه ډیرې ګټې لري. لومړی، موږ خورا ساده عملیات ترلاسه کوو.
دوهم، دا ډیر ګټور دی، ځکه چې موږ دا اتوماتیک کنټرولر یا د ډیسک الماریو سره پیوستون نلرو.
دلته د ماشینونو لوی مقدار شتون لري، او دا یوازې یو څو ډیسکونه دي چې دلته په ماشین کې د برید لپاره راټول شوي.
مګر زیانونه هم شتون لري.
دا حتی د نن ورځې نرخونو کې د SANs کارولو په پرتله نږدې 1,5 ځله ډیر ګران دی. له همدې امله، موږ پریکړه وکړه چې په زړورتیا سره خپل ټول لوی کلستر د محلي هارډ ډرایو سره موټرو ته واړوو او پریکړه یې وکړه چې د هایبرډ حل پریږدو.
زموږ نیمایي ماشینونه د هارډ ډرایو سره کار کوي (ښه، نیمایي نه - شاید 30 سلنه). او پاتې نور زاړه موټرونه دي چې د لومړي ریزرویشن سکیم درلود. موږ په ساده ډول دوی ته ځای ورکړ، ځکه چې موږ نوي ډیټا یا بل څه ته اړتیا نه درلوده، موږ په ساده ډول ماونټونه له یو فزیکي کوربه څخه دوه ته لیږدول.
او موږ اوس د لوستلو لوی ذخیره لرو ، او موږ یې پراخه کړې. که مخکې موږ په یوه ماشین کې یو ذخیره نصب کړې، اوس موږ څلور نصب کوو، د بیلګې په توګه، په یوه جوړه کې. او دا ښه کار کوي.
راځئ چې د هغه څه لنډیز واخلو چې موږ یې ترسره کړل، د څه لپاره مو مبارزه وکړه، او ایا موږ بریالي شو.
پایلې
موږ کاروونکي لرو - تر 33 ملیون پورې.
موږ د شتون درې نقطې لرو - پراګ، میامي، هانګ کانګ.
دوی د کیشینګ پرت لري، کوم چې د چټک محلي ډیسکونو (SSDs) سره موټرونه لري، په کوم کې د NGINX ساده ماشینونه، د هغې access.log او Python ډیمونونه چلیږي، کوم چې دا ټول پروسس کوي او کیچ اداره کوي.
که تاسو وغواړئ، تاسو په خپله پروژه کې یاست، که عکسونه ستاسو لپاره دومره مهم نه وي لکه څنګه چې دوی زموږ لپاره دي، یا که د سوداګرۍ بند کنټرول د پراختیا سرعت او د سرچینو لګښتونه ستاسو لپاره بل لوري ته وي، نو تاسو کولی شئ په خوندي ډول یې ځای په ځای کړئ. د CDN سره، عصري CDNs ښه کار کوي.
بیا د ذخیره کولو پرت راځي ، په کوم کې چې موږ د ماشینونو جوړه کلسترونه لرو چې یو بل بیک اپ کوي ، فایلونه په غیر متناسب ډول له یو څخه بل ته کاپي کیږي کله چې دوی بدلیږي.
سربیره پردې، ځینې دا ماشینونه د محلي هارډ ډرایو سره کار کوي.
ځینې دا ماشینونه د SANs سره وصل دي.
او ، له یوې خوا ، دا د کارولو لپاره خورا اسانه او یو څه ډیر ګټور دی ، له بلې خوا ، دا د ځای په ځای کولو کثافت او په هر ګیګابایټ قیمت کې مناسب دی.
دا د هغه څه د معمارۍ لنډه کتنه ده چې موږ یې ترلاسه کړل او دا ټول څنګه وده وکړه.
د کپتان څخه یو څو نور لارښوونې، خورا ساده دي.
لومړی، که تاسو ناڅاپه پریکړه وکړئ چې تاسو په سمدستي توګه د خپل عکس زیربنا کې هرڅه ښه کولو ته اړتیا لرئ، لومړی اندازه کړئ، ځکه چې شاید هیڅ شی ښه کولو ته اړتیا نلري.
اجازه راکړئ تاسو ته یو مثال درکړم. موږ د ماشینونو یو کلستر لرو چې په چیټونو کې د ضمیمو څخه عکسونه لیږي، او دا سکیم د 2009 راهیسې کار کوي، او هیڅوک یې نه ځوروي. هرڅوک ښه دي، هرڅوک هرڅه خوښوي.
د اندازه کولو لپاره، لومړی د میټریکونو یوه ډله ځړول، دوی ته وګورئ، او بیا پریکړه وکړئ چې تاسو له څه څخه ناخوښه یاست او څه ته اړتیا لرئ چې ښه شي. د دې اندازه کولو لپاره، موږ د پنبا په نوم یو ښه وسیله لرو.
دا تاسو ته اجازه درکوي چې د هرې غوښتنې او ځواب کوډونو لپاره د NGINX څخه خورا تفصيلي احصایې راټول کړئ، او د وخت ویش - هر هغه څه چې تاسو یې غواړئ. دا د مختلف تحلیلي سیسټمونو هر ډول پابندۍ لري ، او بیا تاسو کولی شئ دا ټول په ښکلي ډول وګورئ.
لومړی موږ دا اندازه کړه، بیا مو ښه کړه.
نور. موږ لوستل د کیچ سره اصلاح کوو ، د شارډینګ سره لیکل ، مګر دا یو څرګند ټکی دی.
نور. که تاسو اوس د خپل سیسټم په جوړولو پیل کوئ، نو دا خورا ښه ده چې عکسونه د بدلیدونکي فایلونو په توګه جوړ کړئ. ځکه چې تاسو سمدلاسه د کیچ باطلولو سره د ستونزو ټوله ټولګي له لاسه ورکوئ ، پدې سره چې څنګه منطق باید د عکس سم نسخه ومومي ، او داسې نور.
راځئ چې ووایو چې تاسو سل اپلوډ کړی، بیا یې وګرځوئ، داسې جوړ کړئ چې دا د فزیکي پلوه مختلف فایل و. هغوی. فکر کولو ته اړتیا نشته: اوس به زه یو څه ځای خوندي کړم ، ورته فایل ته به یې ولیکم ، نسخه بدله کړم. دا تل ښه کار نه کوي او وروسته د ډیری سر درد لامل کیږي.
بل ټکی. په الوتنه کې د اندازې په اړه.
مخکې، کله چې کاروونکو یو عکس اپلوډ کړ، موږ سمدلاسه د ټولو مواردو لپاره، د مختلفو مراجعینو لپاره، د اندازې ټوله ډله پرې کړه، او دا ټول په ډیسک کې وو. اوس موږ دا پریښوده.
موږ یوازې درې اصلي اندازې پریښودلې: کوچنۍ، منځنۍ او لوی. موږ په ساده ډول د اندازې څخه نور هرڅه ښکته کوو چې د هغه شاته دی چې موږ ته په Uport کې غوښتنه شوې وه ، موږ په ساده ډول ښکته کچه کوو او کارونکي ته یې ورکوو.
دلته د کیشینګ پرت CPU د دې په پرتله خورا ارزانه ښکاري که چیرې موږ په دوامداره توګه دا اندازې په هر ذخیره کې له سره رامینځته کړو. راځئ چې ووایو چې موږ یو نوی اضافه کول غواړو، دا به یوه میاشت وخت ونیسي - هرچیرې یو سکریپټ چلوي چې دا ټول په ښه توګه ترسره کړي، پرته له دې چې کلستر ویجاړ کړي. هغوی. که تاسو اوس د غوره کولو فرصت لرئ، نو دا به غوره وي چې د امکان تر حده لږ فزیکي اندازې جوړ کړئ، مګر دا چې لږترلږه یو څه ویش وي، ووایئ، درې. او نور هرڅه په ساده ډول د چمتو شوي ماډلونو په کارولو سره په الوتنه کې تنظیم کیدی شي. دا ټول اوس خورا اسانه او د لاسرسي وړ دي.
او زیاتیدونکي غیر متناسب بیک اپ ښه دی.
لکه څنګه چې زموږ تمرین ښودلی، دا سکیم د بدل شوي فایلونو ځنډول شوي کاپي سره ښه کار کوي.
وروستی ټکی هم څرګند دی. که ستاسو زیربنا اوس داسې ستونزې نه لري، مګر یو څه شتون لري چې ماتولی شي، دا به خامخا مات شي کله چې یو څه نور شي. له همدې امله، دا غوره ده چې د دې په اړه مخکې له مخکې فکر وکړئ او د دې سره ستونزې تجربه نه کړئ. دا ټول ما غوښتل ووایم.
تماسونه
»
»
دا راپور د لوړ بار سیسټمونو پراختیا کونکو کنفرانس کې د یوې غوره وینا یوه لیکنه ده . د HighLoad++ 2017 کنفرانس ته له یوې میاشتې څخه لږ وخت پاتې دی.
موږ لا دمخه چمتو یو ، مهالویش اوس په فعاله توګه رامینځته کیږي.
سږکال موږ د معمارۍ او پیمانه کولو موضوع سپړلو ته دوام ورکوو:
- / ایګور واسیلییف
- / دمیتري ایګوروف
- / اناتولي پلاسکوفسکي
- / رومن شیخووتسوف، الیکسی گروماتچیکوف
- / فیلیپ ډیلګاډو
موږ د دې موادو څخه ځینې زموږ د آنلاین روزنې کورس کې د لوړ بار سیسټمونو رامینځته کولو کې هم کاروو د ځانګړي ټاکل شوي لیکونو، مقالو، موادو، ویډیوګانو سلسله ده. زموږ درسي کتاب لا دمخه له 30 څخه ډیر ځانګړي توکي لري. نښلول!
سرچینه: www.habr.com