سلام! زما نوم الیکسي پیانکوف دی، زه د سپورت ماسټر شرکت کې پراختیا کونکی یم. په هغه کې ما وویل چې څنګه د سپورت ماسټر ویب پاڼې کار په 2012 کې پیل شو، کوم نوښتونه چې موږ یې "د فشار له لارې" اداره کړل او برعکس، کوم ریک موږ راټول کړل.
نن زه غواړم هغه فکرونه شریک کړم چې بله موضوع تعقیبوي - د سایټ ایڈمن پینل کې د جاوا بیکینډ لپاره د کیچنګ سیسټم غوره کول. دا پلاټ زما لپاره ځانګړی معنی لري - که څه هم کیسه یوازې د 2 میاشتو لپاره راپورته شوه ، پدې 60 ورځو کې موږ 12-16 ساعته کار وکړ او پرته له یوې ورځې رخصتۍ. ما هیڅکله فکر یا تصور نه کاوه چې دا ممکنه وه چې دومره سخت کار وکړو.
له همدې امله ، ما متن په 2 برخو ویشلی ترڅو دا په بشپړ ډول بار نه کړي. برعکس، لومړۍ برخه به ډیره روښانه وي - چمتو کول، پیژندنه، د کیچ کولو په اړه ځینې نظرونه. که تاسو دمخه تجربه لرونکی پرمخ وړونکی یاست یا د کیچونو سره کار کړی وي ، له تخنیکي اړخ څخه به احتمالا پدې مقاله کې هیڅ نوي نه وي. مګر د یو ځوان لپاره، دا ډول کوچنۍ بیاکتنه کولی شي هغه ته ووایي چې کوم لوري ته وګوري که چیرې هغه ځان په داسې یوه څلور لارې کې ومومي.
کله چې د سپورت ماسټر ویب پاڼې نوې نسخه تولید ته وسپارل شوه، ډاټا په داسې طریقه ترلاسه شوه چې په نرمۍ سره یې واچول شي، خورا اسانه نه و. اساس د سایټ پخوانۍ نسخې (Bitrix) لپاره چمتو شوي میزونه وو، کوم چې باید په ETL کې راښکته شي، نوې بڼه ته راوړل شوي او د لسګونو نورو سیسټمونو څخه د مختلفو کوچنیو شیانو سره بډایه شوي. په سایټ کې د نوي عکس یا محصول توضیحاتو څرګندیدو لپاره ، تاسو باید تر بلې ورځې انتظار وکړئ - یوازې د شپې تازه کول ، په ورځ کې یو ځل.
په لومړي سر کې، تولید ته د تلو له لومړیو اونیو څخه ډیری اندیښنې شتون درلود چې د مینځپانګې مدیرانو لپاره دا ډول ناامني یوه کوچنۍ وه. مګر، لکه څنګه چې هرڅه سم شول، د پروژې پراختیا دوام درلود - څو میاشتې وروسته، د 2015 په پیل کې، موږ په فعاله توګه د اډمین پینل پراختیا پیل کړه. په 2015 او 2016 کې، هرڅه سم روان دي، موږ په منظمه توګه خپروو، د اډمین پینل د ډیرو معلوماتو چمتو کولو پوښښ کوي، او موږ د دې حقیقت لپاره چمتووالی نیسو چې ډیر ژر به زموږ ټیم ته د خورا مهم او پیچلي شی - محصول وسپارل شي. سرکټ (په ټولو محصولاتو کې د معلوماتو بشپړ چمتو کول او ساتنه). مګر د 2017 په دوبي کې ، د اجناسو سرکټ له پیل څخه دمخه ، پروژه به ځان په خورا سخت حالت کې ومومي - دقیقا د کیچ کولو ستونزو له امله. زه غواړم د دې دوه برخې خپرونې په دویمه برخه کې د دې خپرونې په اړه خبرې وکړم.
مګر پدې پوسټ کې به زه له لرې څخه پیل وکړم ، زه به ځینې فکرونه وړاندې کړم - د کیچنګ په اړه نظرونه ، کوم چې د یوې لویې پروژې دمخه د سکرول کولو لپاره به ښه ګام وي.
کله چې د کیچ کولو دنده ترسره کیږي
د کیچ کولو دنده یوازې نه ښکاري. موږ پراختیا کونکي یو، د سافټویر محصول لیکو او غواړو چې دا په تقاضا کې وي. که محصول په تقاضا کې وي او بریالي وي، کاروونکي به راشي. او نور ډیر راځي. او بیا ډیری کارونکي شتون لري او بیا محصول خورا ډیر باریږي.
په لومړیو مرحلو کې، موږ د اصلاح کولو او کوډ فعالیت په اړه فکر نه کوو. اصلي شی فعالیت دی، په چټکۍ سره د پیلوټ رول او د فرضیې معاینه کول. او که بار ډیر شي، موږ اوسپنه پمپ کوو. موږ دا دوه یا درې ځله زیاتوو، پنځه ځله، شاید 10 ځله. دلته یو ځای - مالیات به نور اجازه ورنکړي. د کاروونکو شمیر به څو ځله زیات شي؟ دا به د 2-5-10 په څیر نه وي، مګر که بریالی وي، دا به د 100-1000 څخه تر 100 زرو پورې وي. دا دی، ژر یا وروسته، تاسو باید اصلاح کول ترسره کړئ.
راځئ چې ووایو چې د کوډ ځینې برخې (راځئ چې دې برخې ته فنکشن ووایو) په غیر معمولي ډول ډیر وخت نیسي ، او موږ غواړو د اجرا کولو وخت کم کړو. یو فنکشن ډیټابیس ته لاسرسی کیدی شي ، یا دا د ځینې پیچلي منطق اجرا کیدی شي - اصلي شی دا دی چې دا اجرا کول ډیر وخت نیسي. تاسو د اعدام وخت څومره کمولی شئ؟ په حد کې، تاسو کولی شئ دا صفر ته راټیټ کړئ، نور نه. څنګه کولی شئ د اعدام وخت صفر ته راټیټ کړئ؟ ځواب: اعدام په بشپړه توګه له منځه یوسو. پرځای یې، سمدلاسه پایله بیرته ورکړئ. څنګه کولای شو چی پایله معلوم کړي؟ ځواب: یا یې حساب کړئ یا بل ځای وګورئ. دا د محاسبې لپاره ډیر وخت نیسي. او جاسوسي کول د بیلګې په توګه، د پایلې په یادولو کې دي چې فنکشن وروستی ځل تولید کړی کله چې د ورته پیرامیټونو سره ویل کیږي.
دا دی، د فعالیت پلي کول زموږ لپاره مهم ندي. دا یوازې کافي ده چې پوه شئ چې په کوم پیرامیټرو پایله پورې اړه لري. بیا ، که چیرې د پیرامیټر ارزښتونه د یو څیز په توګه ښودل شوي وي چې په ځینې ذخیره کې د کیلي په توګه کارول کیدی شي ، نو د محاسبې پایله خوندي کیدی شي او بل ځل چې ورته لاسرسی وي لوستل کیدی شي. که د پایلې لیکل او لوستل د فعالیت اجرا کولو په پرتله ګړندي وي ، موږ د سرعت له مخې ګټه لرو. د ګټې اندازه کیدای شي 100، 1000 او 100 زرو ته ورسیږي (10^ 5 یو استثناء ده، مګر د کافي وروسته پاتې کیدو په صورت کې، دا خورا ممکنه ده).
د کیشینګ سیسټم لپاره اساسي اړتیاوې
لومړی شی چې ممکن د کیچنګ سیسټم لپاره اړتیا وي د ګړندي لوستلو سرعت دی او تر یو څه لږ حد پورې د لیکلو سرعت دی. دا ریښتیا ده، مګر یوازې تر هغه چې موږ سیسټم تولید ته راوباسي.
راځئ چې دا قضیه ولوبوو.
راځئ چې ووایو موږ اوسنی بار د هارډویر سره چمتو کړی او اوس په تدریجي ډول کیچنګ معرفي کوو. د کاروونکو شمیر یو څه وده کوي ، بار وده کوي - موږ یو څه کیچ اضافه کوو ، دلته او هلته یې پیچ کوو. دا د یو څه وخت لپاره دوام لري، او اوس درنې دندې په عملي توګه نور نه ویل کیږي - ټول اصلي بار په کیچ کې راځي. پدې وخت کې د کاروونکو شمیر N ځله ډیر شوی.
او که چیرې د هارډویر لومړني عرضه 2-5 ځله وي ، نو د کیچ په مرسته موږ کولی شو د 10 فکتور لخوا فعالیت ښه کړو یا په ښه حالت کې ، د 100 فکتور لخوا ، په ځینو ځایونو کې شاید د فاکتور لخوا د 1000 څخه. دا په ورته هارډویر کې - موږ 100 ځله ډیرې غوښتنې پروسس کوو. عالي ، تاسو د جنجربریډ مستحق یاست!
مګر اوس، په یوه ښه شیبه کې، په تصادفي ډول، سیسټم خراب شو او کیچ سقوط وکړ. هیڅ ځانګړی ندی - په هرصورت ، کیچ د اړتیا پراساس غوره شوی و "د لوړ لوستلو او لیکلو سرعت ، پاتې هیڅ اهمیت نلري."
د پیل شوي بار په پرتله، زموږ د اوسپنې ذخیره 2-5 ځله وه، او پدې وخت کې بار 10-100 ځله زیات شوی. د کیچ په کارولو سره ، موږ د درنو کارونو لپاره زنګونه لرې کړل او له همدې امله هرڅه کار کوي. او اوس، د کیچ پرته، زموږ سیسټم به څو ځله سست شي؟ زموږ به څه حال وي؟ سیسټم به سقوط وکړي.
حتی که زموږ زیرمه خرابه شوې نه وي ، مګر یوازې د یو څه وخت لپاره پاکه شوې وه ، نو دا به تودوخې ته اړتیا ولري ، او دا به یو څه وخت ونیسي. او د دې وخت په جریان کې، اصلي بار به په فعالیت باندې راشي.
پایله: په لوړه کچه بار شوي تولید پروژې د کیچنګ سیسټم ته اړتیا لري نه یوازې د لوړ لوستلو او لیکلو سرعت لري ، بلکه د معلوماتو خوندیتوب او د ناکامیو پروړاندې مقاومت هم تضمینوي.
د انتخاب درد
په یوه پروژه کې د اډمین پینل سره، انتخاب په دې ډول روان شو: لومړی موږ هیزلکاسټ نصب کړ، ځکه موږ دمخه د اصلي سایټ تجربې څخه د دې محصول سره آشنا یو. مګر دلته دا انتخاب ناکام شو - زموږ د بار پروفایل لاندې ، هیزلکاسټ نه یوازې ورو دی ، مګر خورا ورو. او په هغه وخت کې موږ لا دمخه د خوشې کولو نیټه لاسلیک کړې وه.
سپوئلر: په حقیقت کې وضعیت څنګه رامینځته شو چې موږ دومره لوی معامله له لاسه ورکړه او د شدید او کړکیچ حالت سره پای ته ورسیدو - زه به تاسو ته په دویمه برخه کې ووایم - او موږ څنګه پای ته ورسیدو او څنګه بهر شو. مګر اوس - زه به یوازې ووایم چې دا خورا فشار و ، او "فکر کول - یو څه زه فکر نشم کولی ، موږ بوتل ماتوو." "د بوتل وهل" هم یو سپیلر دی، په دې اړه نور وروسته.
هغه څه چې موږ وکړل:
- موږ د ټولو سیسټمونو لیست جوړوو چې ګوګل او StackOverflow وړاندیز کوي. له 30 څخه لږ څه
- موږ ازموینې د تولید لپاره ځانګړي بار سره لیکو. د دې کولو لپاره، موږ هغه معلومات ثبت کړل چې د سیسټم له لارې د تولید چاپیریال کې تیریږي - د ډیټا لپاره یو ډول سنیفیر په شبکه کې نه، مګر په سیسټم کې دننه. دقیقا دا معلومات په ازموینو کې کارول شوي.
- د ټول ټیم سره، هرڅوک د لیست څخه راتلونکی سیسټم غوره کوي، تنظیموي، او ازموینې پرمخ وړي. دا ازموینه نه پاس کوي ، دا بار نه وړي - موږ یې غورځوو او په لیکه کې راتلونکي ته ځو.
- په 17 سیسټم کې دا څرګنده شوه چې هر څه نا امید وو. د بوتل وهل بند کړئ، دا د جدي فکر کولو وخت دی.
مګر دا یو اختیار دی کله چې تاسو اړتیا لرئ یو سیسټم غوره کړئ چې مخکې چمتو شوي ازموینو کې به "د سرعت له لارې ترلاسه شي". څه که چیرې لاهم داسې ازموینې شتون نلري او تاسو غواړئ ژر تر ژره غوره کړئ؟
راځئ چې دا اختیار تقلید کړو (دا تصور کول ګران دي چې یو منځنی + پراختیا کونکی په خلا کې ژوند کوي، او د انتخاب په وخت کې لا تر اوسه د هغه غوره توب رسمي نه دی چې کوم محصول لومړی هڅه وکړي - له همدې امله، نور استدلال د تیوریسټ / فلسفې څخه ډیر دی. د یو ځوان په اړه).
د اړتیاو په اړه پریکړه کولو سره، موږ به د بکس څخه د حل لاره غوره کړو. ولې څرخ بیا ایجاد کړئ: موږ به لاړ شو او یو چمتو شوی کیچنګ سیسټم واخلو.
که تاسو یوازې پیل کوئ او ګوګل یې کوئ، نو امر ورکړئ یا واخلئ، مګر په عموم کې، لارښوونې به داسې وي. له هرڅه دمخه ، تاسو به د ریډیس سره مخ شئ ، دا هرچیرې اوریدل کیږي. بیا به تاسو ومومئ چې EhCache ترټولو زوړ او خورا ثابت سیسټم دی. بیا به موږ د ترنتول په اړه ولیکئ، یو کورني پرمختګ چې د حل یو ځانګړی اړخ لري. او همدارنګه Ignite، ځکه چې دا اوس د شهرت په وده کې دی او د SberTech ملاتړ څخه خوند اخلي. په پای کې هزیلکاسټ هم شتون لري، ځکه چې د تصدۍ نړۍ کې دا ډیری وختونه د لوی شرکتونو ترمنځ ښکاري.
لیست بشپړ ندی؛ په لسګونو سیسټمونه شتون لري. او موږ به یوازې یو شی خراب کړو. راځئ چې د "ښکلا سیالۍ" لپاره غوره شوي 5 سیسټمونه واخلو او انتخاب وکړو. ګټونکي به څوک وي؟
Redis
موږ هغه څه لوستل چې دوی په رسمي ویب پاڼه کې لیکي.
- د خلاصې سرچینې پروژه. په حافظه کې د معلوماتو ذخیره کولو وړاندیز کوي، د ډیسک د خوندي کولو وړتیا، د اتوماتیک ویشلو، لوړ شتون او د شبکې بندیدو څخه بیا رغونه.
داسې بریښي چې هرڅه سم دي ، تاسو کولی شئ دا واخلئ او پیچ یې کړئ - هرڅه چې تاسو ورته اړتیا لرئ ، دا کوي. مګر یوازې د ساتیرۍ لپاره ، راځئ چې نورو نوماندانو ته وګورو.
EhCache
- "د جاوا لپاره ترټولو پراخه کارول شوې زیرمه" (د رسمي ویب پا fromې څخه د شعار ژباړه). همدارنګه خلاص سرچینه. او بیا موږ پوهیږو چې ریډیس د جاوا لپاره ندي ، مګر عمومي ، او د دې سره د متقابل عمل کولو لپاره تاسو ریپر ته اړتیا لرئ. او EhCache به ډیر اسانه وي. نظام نور څه ژمنه کوي؟ اعتبار، ثابت، بشپړ فعالیت. ښه، دا هم تر ټولو عام دی. او د ټیرابایټ ډیټا ذخیره کوي.
ریډیس هیر شوی، زه د EhCache غوره کولو لپاره چمتو یم.
مګر د وطن پالنې احساس ما دې ته اړوي چې وګورم چې د ترنټول په اړه څه ښه دي.
ترنتول
- د "ریښتیني وخت ډیټا ادغام پلیټ فارم" نومونه پوره کوي. دا خورا پیچلي ښکاري، نو موږ پاڼه په تفصیل سره ولولئ او یو لوړ بیان ومومئ: "په رام کې د معلوماتو 100٪ زیرمه کوي." دا باید پوښتنې راپورته کړي - په هرصورت، د حافظې په پرتله ډیر معلومات شتون لري. توضیح دا دی چې دا پدې معنی ده چې ټارنټول د حافظې څخه ډیسک ته ډیټا لیکلو لپاره سیریلائزیشن نه چلوي. پرځای یې، دا د سیسټم ټیټې کچې ځانګړتیاوې کاروي، کله چې حافظه په ساده ډول د فایل سیسټم سره د خورا ښه I/O فعالیت سره نقشه کیږي. په عموم کې، دوی یو څه په زړه پوري او ښه وکړل.
راځئ چې پلي کولو ته وګورو: Mail.ru کارپوریټ لویه لاره، Avito، Beeline، Megafon، Alfa-Bank، Gazprom ...
که چیرې د ترنټول په اړه لاهم شکونه شتون ولري ، نو په ماسټر کارډ کې د پلي کولو قضیه ما پای ته رسوي. زه ترنتول واخلم.
خو په هر حال…
ناڅاپه
… ایا یو څه نور هم شته ، د "په حافظه کې کمپیوټري پلیټ فارم ... په حافظه کې د پیټابایټ ډیټا سرعت" په توګه بل شوی. دلته ډیری ګټې هم شتون لري: په حافظه کې توزیع شوي کیچ ، د کلیدي ارزښت خورا ګړندی ذخیره او کیچ ، افقی اندازه کول ، لوړ شتون ، سخت بشپړتیا. په عموم کې، دا معلومه شوه چې ترټولو چټک Ignite دی.
تطبیقات: Sberbank, American Airlines, Yahoo! جاپان. او بیا زه پوه شوم چې Ignite یوازې په سبربینک کې نه پلي کیږي ، مګر د SberTech ټیم خپل خلک پخپله د Ignite ټیم ته لیږي ترڅو محصول پاک کړي. دا په بشپړ ډول زړه راښکونکی دی او زه چمتو یم چې Ignite واخلم.
دا په بشپړ ډول روښانه نده چې ولې ، زه پنځم ټکي ته ګورم.
هیزلکاسټ
زه سایټ ته ځم لوستل. او دا معلومه شوه چې د توزیع شوي کیچنګ لپاره ترټولو ګړندی حل هیزلکاسټ دی. دا د نورو ټولو حلونو په پرتله ګړندۍ امرونه دي او په عموم کې دا د حافظې ډیټا گرډ په ساحه کې مشر دی. په دې پس منظر کې، د بل څه اخیستل د ځان درناوی نه دی. دا د معلوماتو له لاسه ورکولو پرته د کلسټر دوامداره عملیاتو لپاره بې ځایه ډیټا ذخیره هم کاروي.
دا دی، زه چمتو یم چې هیزلکاسټ واخلم.
پرتله کول
مګر که تاسو وګورئ، ټول پنځه نوماندان په داسې ډول بیان شوي چې هر یو یې غوره دی. څنګه انتخاب کړئ؟ موږ کولی شو وګورو چې کوم یو خورا مشهور دی، د پرتله کولو لپاره وګورئ، او سر درد به لاړ شي.
موږ داسې یو پیدا کوو ، زموږ 5 سیسټمونه غوره کړئ.
دلته دوی ترتیب شوي دي: ریډیس په سر کې دی ، هیزلکاسټ په دوهم ځای کې دی ، ټرانټول او ایګنیټ شهرت ترلاسه کوي ، EhCache شتون لري او ورته پاتې دی.
مګر راځئ چې وګورو : ویب پاڼو ته لینکونه، په سیسټم کې عمومي دلچسپي، د کار وړاندیزونه - عالي! دا دی، کله چې زما سیسټم ناکام شي، زه به ووایم: "نه، دا د اعتبار وړ دی! د کار ډیری وړاندیزونه شتون لري ... " دا ډول ساده پرتله به ونه کړي.
دا ټول سیسټمونه یوازې د کیشینګ سیسټمونه ندي. دوی ډیر فعالیت هم لري، پشمول کله چې ډاټا د پروسس لپاره پیرودونکي ته پمپ نه وي، مګر برعکس: هغه کوډ چې په ډیټا کې اجرا کولو ته اړتیا لري سرور ته حرکت کوي، هلته اجرا کیږي، او پایله بیرته راستانه کیږي. او دوی ډیری وختونه د کیچ کولو لپاره د جلا سیسټم په توګه نه ګڼل کیږي.
ښه، راځئ چې تسلیم نه شو، راځئ چې د سیسټمونو مستقیم پرتله کړو. راځئ چې غوره دوه اختیارونه واخلو - ریډیس او هیزلکاسټ. موږ د سرعت سره علاقه لرو، او موږ به یې د دې پیرامیټر پراساس پرتله کړو.
Hz vs Redis
موږ دا پیدا کوو :
نیلي ریډیس دی ، سور هیزلکاسټ دی. هیزلکاسټ هرچیرې وګټي ، او د دې لپاره دلیل شتون لري: دا څو تارونه لري ، خورا مطلوب دی ، هر تار د خپل ویش سره کار کوي ، نو هیڅ بلاک شتون نلري. او ریډیس واحد تار شوی دی؛ دا د عصري ملټي کور CPUs څخه ګټه نه لري. هیزلکاسټ غیر متناسب I/O لري، Redis-Jedis د بلاک کولو ساکټونه لري. په هرصورت ، هیزلکاسټ بائنری پروتوکول کاروي ، او ریډیس د متن متمرکز دی ، پدې معنی چې دا غیر موثر دی.
یوازې په قضیه کې، راځئ چې د پرتله کولو بلې سرچینې ته وګرځو. هغه به موږ ته څه وښيي؟
Redis vs Hz
بل :
دلته، برعکس، سور ریډیس دی. دا دی ، ریډیس د فعالیت په شرایطو کې هیزلکاسټ ته وده ورکوي. هیزلکاسټ لومړی پرتله وګټله ، ریډیس دویمه وګټله. په خورا دقیق ډول تشریح کړه چې ولې هیزلکاسټ پخوانۍ پرتله وګټله.
دا معلومه شوه چې د لومړي پایله په حقیقت کې درغلي وه: ریډیس په بیس بکس کې اخیستل شوی و، او هیزلکاسټ د ازموینې قضیې لپاره جوړ شوی و. بیا دا معلومه شوه: لومړی، موږ په هیچا باور نشو کولی، او دویم، کله چې موږ په پای کې یو سیسټم غوره کړو، موږ لاهم اړتیا لرو چې دا په سمه توګه تنظیم کړو. پدې ترتیباتو کې لسګونه، نږدې سلګونه پیرامیټونه شامل دي.
بوتل راښکته کول
او زه کولی شم ټوله پروسه تشریح کړم چې موږ اوس د لاندې استعار سره ترسره کړی دی: "د بوتل ماتول." دا دی ، اوس تاسو اړتیا نلرئ برنامه وکړئ ، اوس اصلي شی دا دی چې د سټیک اوور فلو لوستلو وړ اوسئ. او زه په خپل ټیم کې یو کس لرم، یو مسلکي، چې په جدي شیبو کې ورته ورته کار کوي.
هغه څه کوي؟ هغه مات شوی شی ویني، د سټیک ټریس ګوري، له هغې څخه ځینې ټکي اخلي (کوم چې په برنامه کې د هغه تخصص دي)، په ګوګل کې لټون کوي ، د ځوابونو په منځ کې د سټیک اوور فلو ومومي. پرته له لوستلو، پرته له فکر کولو، د پوښتنې د ځوابونو په منځ کې، هغه یو څه غوره کوي چې د "دا او هغه" جملې ته ورته وي (داسې ځواب غوره کول د هغه وړتیا ده، ځکه چې دا تل هغه ځواب نه وي چې ډیری خوښې ترلاسه کړي) تطبیق کیږي، ښکاري: که یو څه بدل شوی وي، نو ښه. که دا نه وي بدل شوی، بیرته یې وګرځوئ. او د لانچ - چیک لټون تکرار کړئ. او په دې اراده توګه، هغه ډاډ ترلاسه کوي چې کوډ یو څه وروسته کار کوي. هغه نه پوهیږي ولې، هغه نه پوهیږي چې هغه څه کړي، هغه نشي کولی تشریح کړي. خو! دا انفیکشن کار کوي. او "اور مړ شوی دی." اوس راځئ چې معلومه کړو چې موږ څه وکړل. کله چې برنامه کار کوي ، دا د اندازې ترتیب اسانه دی. او دا ډیر وخت خوندي کوي.
دا طریقه د دې مثال سره خورا ښه تشریح شوې.
دا یو وخت خورا مشهور و چې په بوتل کې د سیل کښتۍ راټولول. په ورته وخت کې، کښتۍ لویه او نازکه ده، او د بوتل غاړه ډیره تنګ ده، دا ناشونې ده چې دننه یې فشار ورکړئ. څنګه یې راټول کړئ؟
داسې طریقه شتون لري، خورا چټک او خورا اغیزمن.
کښتۍ د کوچنیو شیانو یوه ډله جوړه کړه: لرګي، رسۍ، سیل، ګولۍ. موږ دا ټول په بوتل کې واچوو.
موږ بوتل د دواړو لاسونو سره اخلو او په ټکولو پیل کوو. موږ هغه وخوځوو او وخوځوو. او معمولا دا د بشپړ کثافاتو په توګه وګرځي، البته. خو کله کله. ځینې وختونه دا په کښتۍ بدلیږي! په دقیق ډول، یو څه د کښتۍ سره ورته.
موږ دا یو څه یو چا ته وښایه: "سریوګا، تاسو ګورئ!؟" او په حقیقت کې، له لرې څخه دا د کښتۍ په څیر ښکاري. مګر دې ته اجازه نه ورکول کیږي چې دوام ومومي.
بله لاره هم شته. دوی د ډیرو پرمختللو هلکانو لخوا کارول کیږي، لکه هیکرز.
ما دې سړي ته دنده ورکړه، هغه هر څه وکړل او لاړ. او تاسو ګورئ - داسې ښکاري چې دا ترسره شوی. او یو څه وروسته ، کله چې کوډ حتمي کیدو ته اړتیا لري ، دا د هغه له امله پیل کیږي ... دا ښه ده چې هغه لا دمخه په وتښتي. دا هغه هلکان دي چې د بوتل مثال په کارولو سره به دا کار وکړي: تاسو وګورئ، چیرته چې لاندې دی، شیشې ځړیږي. او دا په بشپړه توګه روښانه نده چې ایا دا شفافه ده که نه. بیا "هیکرانو" دا لاندینۍ ټوټه پرې کړه، هلته یې کښتۍ دننه کړه، بیا یې لاندې بیا چپه کړه، او داسې ښکاري لکه څنګه چې باید وي.
د ستونزې د تنظیم کولو له نظره، هرڅه سم ښکاري. مګر د مثال په توګه د کښتیو کارول: ولې دا کښتۍ په بشپړ ډول جوړه کړئ ، څوک ورته اړتیا لري؟ دا هیڅ فعالیت نه وړاندې کوي. معمولا دا ډول کښتۍ خورا لوړ پوړو خلکو ته ډالۍ وي ، څوک چې دا د یو ډول سمبول په توګه ، د نښې په توګه د دوی په پورتنۍ شیلف کې ایږدي. او که داسې سړی، د لوی کاروبار مشر یا لوړ پوړی چارواکی وي، د داسې هک کولو لپاره به څنګه بیرغ ودریږي، چې غاړه یې پرې شوې وي؟ دا به ښه وي که هغه هیڅکله د دې په اړه نه پوهیږي. نو، دوی څنګه دا کښتۍ جوړوي چې یو مهم کس ته ورکول کیدی شي؟
یوازینی کلیدي ځای چې تاسو واقعیا هیڅ نشئ کولی د بدن بدن دی. او د کښتۍ خولۍ په غاړه کې سم فټ کیږي. پداسې حال کې چې کښتۍ د بوتل څخه بهر راټولیږي. مګر دا یوازې د کښتۍ راټولول ندي ، دا د ګاڼو ریښتیني هنر دی. اجزاو ته ځانګړي لیورونه اضافه شوي ، کوم چې بیا دوی ته د پورته کیدو اجازه ورکوي. د مثال په توګه، سیلونه پوښل شوي، په احتیاط سره دننه راوړل شوي، او بیا، د ټیزرونو په مرسته، دوی په خورا دقیق ډول، دقت سره راښکته او پورته کیږي. پایله د هنر کار دی چې د روښانه ضمیر او ویاړ سره ډالۍ کیدی شي.
او که موږ غواړو چې پروژه بریالۍ وي، په ټیم کې باید لږترلږه یو زیور وي. هغه څوک چې د محصول کیفیت ته پاملرنه کوي او ټول اړخونه په پام کې نیسي، پرته له دې چې هیڅ شی قرباني کړي، حتی د فشار په شیبو کې، کله چې شرایط د مهم لګښت په بیړنۍ توګه ترسره کولو ته اړتیا لري. ټولې بریالۍ پروژې چې دوامدارې دي، چې د وخت په ازمایښت کې ولاړې دي، په همدې اصولو جوړې شوې دي. د دوی په اړه یو څه خورا دقیق او ځانګړی دی، یو څه چې د ټولو شته امکاناتو څخه ګټه پورته کوي. په مثال کې په بوتل کې د کښتۍ سره ، دا حقیقت چې د کښتۍ خولۍ د غاړې څخه تیریږي لوبول کیږي.
زموږ د کیشینګ سرور غوره کولو دندې ته راستنیدل، دا طریقه څنګه پلي کیدی شي؟ زه د ټولو موجود سیسټمونو څخه د غوره کولو دا اختیار وړاندیز کوم - بوتل مه وهئ، غوره مه کوئ، مګر وګورئ چې دوی په اصولو کې څه لري، د سیسټم غوره کولو په وخت کې څه باید وګورئ.
چیرې چې د بوتل غاړې ته ګورئ
راځئ هڅه وکړو چې بوتل و نه غورځوو، نه د هر هغه څه څخه چې هلته شتون لري یو له بل سره تیریږي، مګر راځئ چې وګورو چې څه ستونزې به رامینځته شي که چیرې موږ ناڅاپه د خپلې دندې لپاره، دا ډول سیسټم پخپله ډیزاین کړو. البته، موږ به موټرسایکل راټول نه کړو، مګر موږ به دا ډیاګرام وکاروو ترڅو موږ سره مرسته وکړو چې معلومه کړو چې د محصول توضیحاتو کې کومو ټکو ته پام وکړئ. راځئ چې داسې یو انځور جوړ کړو.
که سیسټم وویشل شي، نو موږ به څو سرورونه ولرو (6). راځئ چې ووایو چې څلور شتون لري (دا مناسبه ده چې دوی په عکس کې ځای په ځای کړئ، مګر البته، د دوی ډیری یې شتون لري څومره چې تاسو یې غواړئ). که سرورونه په مختلفو نوډونو کې وي، دا پدې مانا ده چې دوی ټول یو څه کوډ چلوي چې د دې ډاډ ترلاسه کولو مسولیت لري چې دا نوډونه کلستر جوړوي او د وقفې په صورت کې، یو بل سره نښلوي او پیژني.
موږ د کوډ منطق (2) ته هم اړتیا لرو، کوم چې په حقیقت کې د کیشینګ په اړه دی. پیرودونکي د دې کوډ سره د ځینې API له لارې اړیکه لري. د پیرودونکي کوډ (1) کیدی شي یا په ورته JVM کې وي یا د شبکې له لارې لاسرسی ومومي. دننه پلي شوی منطق دا پریکړه کوي چې کوم شیان په زیرمه کې پریږدي او کوم یې بهر وغورځوي. موږ د کیچ ذخیره کولو لپاره (3) حافظه کاروو ، مګر که اړتیا وي ، موږ کولی شو ځینې ډیټا په ډیسک کې خوندي کړو (4).
راځئ وګورو چې بار به په کومو برخو کې واقع شي. په حقیقت کې، هر تیر او هر نوډ به پورته شي. لومړی، د پیرودونکي کوډ او api تر منځ، که دا د شبکې اړیکه وي، کمښت د پام وړ کیدی شي. دوهم ، پخپله د api په چوکاټ کې - که موږ دا د پیچلي منطق سره ډیر کړو ، نو موږ کولی شو د CPU سره ستونزو سره مخ شو. او دا به ښه وي که منطق په حافظه کې وخت ضایع نکړي. او د فایل سیسټم سره تعامل پاتې دی - په معمول نسخه کې دا سیریل کول / بحال کول او لیکل / لوستل دي.
بل د کلستر سره تعامل دی. ډیری احتمال، دا به په ورته سیسټم کې وي، مګر دا په جلا توګه کیدی شي. دلته تاسو اړتیا لرئ دې ته د ډیټا لیږد ، د ډیټا سیریل کولو سرعت او د کلستر ترمینځ متقابل عمل هم په پام کې ونیسئ.
اوس، له یوې خوا، موږ تصور کولی شو چې زموږ د کوډ څخه غوښتنې پروسس کولو په وخت کې د کیچ سیسټم کې "کوم ګیرونه به بدل شي" او له بلې خوا، موږ اټکل کولی شو چې زموږ کوډ به د دې سیسټم لپاره څه او څومره غوښتنې رامینځته کړي. دا د ډیر یا لږ هوښیار انتخاب کولو لپاره کافي دي - زموږ د کارونې قضیې لپاره سیسټم غوره کولو لپاره.
هیزلکاسټ
راځئ وګورو چې دا تخریب زموږ لیست ته څنګه پلي کړو. د مثال په توګه، Hazelcast.
د Hazelcast څخه د معلوماتو د ساتلو / اخیستلو لپاره، د پیرودونکي کوډ (1) api ته لاسرسی لري. Hz تاسو ته اجازه درکوي چې سرور د سرایت شوي په توګه پرمخ بوځي، او پدې حالت کې، api ته لاسرسی د JVM دننه یو میتود دی، کوم چې وړیا ګڼل کیدی شي.
په (2) کې د منطق د کار کولو لپاره، Hz د سیریل شوي کیلي د بایټ سرې په هش باندې تکیه کوي - دا چې کیلي به په هر حالت کې سیریل شي. دا د هرز لپاره ناگزیر دی.
د ایستلو تګلارې په ښه توګه پلي کیږي، مګر د ځانګړو قضیو لپاره تاسو کولی شئ خپل ځان اضافه کړئ. تاسو د دې برخې په اړه اندیښنه نلرئ.
ذخیره (4) کولی شي نښلول شي. غوره. د سرایت کولو لپاره تعامل (5) سمدستي ګڼل کیدی شي. په کلستر کې د نوډونو ترمنځ د معلوماتو تبادله (6) - هو، دا شتون لري. دا د سرعت په لګښت کې د غلطۍ زغم کې پانګه اچونه ده. د هرز فیچر Near-cache تاسو ته اجازه درکوي قیمت کم کړئ - په کلستر کې د نورو نوډونو څخه ترلاسه شوي معلومات به زیرمه شي.
په داسې شرایطو کې د سرعت زیاتولو لپاره څه کیدی شي؟
د مثال په توګه، په (2) کې د کلیدي سریال کولو څخه مخنیوي لپاره - د هزیلکاسټ په سر کې یو بل کیچ ضمیمه کړئ، د غوره معلوماتو لپاره. سپورت ماسټر د دې هدف لپاره کافین غوره کړ.
په کچه (6) کې د ګرځیدو لپاره، Hz دوه ډوله ذخیره وړاندې کوي: IMap او ReplicatedMap.
دا د یادونې وړ ده چې څنګه هیزلکاسټ د سپورت ماسټر ټیکنالوژۍ سټیک ته ورسید.
په 2012 کې، کله چې موږ د راتلونکي سایټ په لومړي پیلوټ کې کار کاوه، دا Hazelcast وه چې لومړی لینک وګرځید چې د لټون انجن بیرته راستانه شو. پیژندګلوی "لومړی ځل" پیل کړ - موږ د دې حقیقت له امله متوجه شو چې یوازې دوه ساعته وروسته ، کله چې موږ سیسټم ته Hz خراب کړ ، دا کار وکړ. او دا ښه کار وکړ. د ورځې په پای کې موږ یو شمیر ازموینې بشپړې کړې او خوشحاله وو. او د ځواک دا زیرمه د هغه حیرانتیاو د له منځه وړلو لپاره کافي وه چې Hz د وخت په تیریدو سره وغورځوله. اوس د سپورت ماسټر ټیم هیڅ دلیل نلري چې هیزلکاسټ پریږدي.
مګر دا ډول دلیلونه لکه "د لټون انجن کې لومړی لینک" او "HelloWorld په چټکۍ سره راټول شوي"، البته، یو استثنا او د هغه شیبې ځانګړتیا ده چې په هغه وخت کې چې انتخاب ترسره شو. د غوره شوي سیسټم لپاره اصلي ازموینې تولید ته د خوشې کیدو سره پیل کیږي ، او دا پدې مرحله کې ده چې تاسو باید د هر سیسټم غوره کولو پرمهال پاملرنه وکړئ ، پشمول د کیچ. په حقیقت کې، زموږ په قضیه کې موږ کولی شو ووایو چې موږ په ناڅاپي توګه هیزلکاسټ غوره کړ، مګر بیا دا معلومه شوه چې موږ په سمه توګه غوره کړی.
د تولید لپاره، ډیر مهم: څارنه، په انفرادي نوډونو کې د ناکامیو اداره کول، د معلوماتو نقل کول، د اندازه کولو لګښت. دا د دې ارزښت لري چې هغه دندو ته پام وکړئ چې د سیسټم ساتنې پرمهال رامینځته کیږي - کله چې بار له پلان شوي څخه لسګونه ځله لوړ وي ، کله چې موږ په ناڅاپي ډول یو څه په غلط ځای کې اپلوډ کوو ، کله چې موږ اړتیا لرو نوې نسخه وړاندې کړو. د کوډ څخه، ډاټا بدل کړئ او دا د پیرودونکو لپاره بې پامه وکړئ.
د دې ټولو اړتیاو لپاره، هیزلکاسټ یقینا د بل سره سمون لري.
نور بیا
مګر هیزلکاسټ درملنه نه ده. په 2017 کې، موږ د مدیر کیچ لپاره هیزلکاسټ غوره کړ، په ساده ډول د تیرو تجربو څخه د ښه تاثیراتو پراساس. دې په یوه خورا ظالمانه ټوکه کې کلیدي رول ولوباوه، چې له امله یې موږ ځان په یو ستونزمن حالت کې وموند او د 60 ورځو لپاره "په زړورتیا" له هغې څخه ووتل. مګر په دې اړه نور په راتلونکې برخه کې.
په عین حال کې... نوی کوډ مو مبارک شه!
سرچینه: www.habr.com