چگونه ما در Sportmaster یک سیستم کش را انتخاب کردیم. قسمت 1

سلام! نام من الکسی پیانکوف است، من یک توسعه دهنده در شرکت Sportmaster هستم. در آن پست من گفتم که چگونه کار در وب سایت Sportmaster در سال 2012 شروع شد، چه ابتکاراتی را موفق به انجام آن کردیم و بالعکس، چه چنگک جمع آوری کردیم.

امروز می‌خواهم افکاری را به اشتراک بگذارم که موضوع دیگری را دنبال می‌کنند - انتخاب یک سیستم کش برای باطن جاوا در ناحیه مدیریت سایت. این طرح برای من معنای خاصی دارد - اگرچه داستان فقط 2 ماه پیش رفت، اما در این 60 روز 12-16 ساعت و بدون یک روز تعطیل کار کردیم. هیچ وقت فکر و تصور نمی کردم که می شود اینقدر سخت کار کرد.

بنابراین متن را به 2 قسمت تقسیم کردم تا به طور کامل بارگذاری نشود. برعکس، بخش اول بسیار سبک خواهد بود - آماده سازی، مقدمه، برخی ملاحظات در مورد اینکه ذخیره سازی چیست. اگر قبلاً یک توسعه‌دهنده با تجربه هستید یا با کش کار کرده‌اید، از نظر فنی به احتمال زیاد چیز جدیدی در این مقاله وجود نخواهد داشت. اما برای یک جوان، چنین بررسی کوچکی می تواند به او بگوید اگر در چنین چهارراهی قرار گرفت، به کدام سمت نگاه کند.

زمانی که نسخه جدید وب سایت Sportmaster وارد مرحله تولید شد، داده ها به گونه ای دریافت شد که به بیان ساده، چندان راحت نبود. اساس جدول هایی بود که برای نسخه قبلی سایت (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 برابر شد. با استفاده از حافظه پنهان، تماس‌های مربوط به عملکردهای سنگین را حذف کردیم و بنابراین همه چیز کار کرد. و حالا بدون کش چند بار سرعت سیستم ما کم می شود؟ چه اتفاقی برای ما خواهد افتاد؟ سیستم سقوط خواهد کرد.

حتی اگر حافظه پنهان ما خراب نشده باشد، بلکه فقط برای مدتی پاک شده است، باید گرم شود و این مدتی طول می کشد. و در این مدت، بار اصلی بر روی عملکرد خواهد افتاد.

نتیجه‌گیری: پروژه‌های تولیدی با بارگذاری بالا به یک سیستم کش نه تنها برای داشتن سرعت خواندن و نوشتن بالا، بلکه برای اطمینان از ایمنی داده‌ها و مقاومت در برابر خرابی نیاز دارند.

آرد انتخاب

در پروژه ای با پنل مدیریت، انتخاب به این صورت انجام شد: ابتدا Hazelcast را نصب کردیم، زیرا قبلا از تجربه سایت اصلی با این محصول آشنا شده بودیم. اما در اینجا این انتخاب ناموفق بود - تحت نمایه بار ما، Hazelcast نه تنها کند است، بلکه به طرز وحشتناکی کند است. و در آن زمان ما قبلا برای تاریخ انتشار ثبت نام کرده بودیم.

اسپویلر: دقیقاً چگونه شرایط ایجاد شد که ما چنین معامله بزرگی را از دست دادیم و به یک موقعیت حاد و پرتنش رسیدیم - در قسمت دوم به شما خواهم گفت - و چگونه به پایان رسیدیم و چگونه از آن خارج شدیم. اما اکنون - فقط می گویم که استرس زیادی بود، و "فکر کردن - به نوعی نمی توانم فکر کنم، ما بطری را تکان می دهیم." "تکان دادن بطری" نیز یک اسپویلر است که بعداً در مورد آن توضیح خواهیم داد.

چه کار کردیم:

1. ما لیستی از تمام سیستم هایی که گوگل و StackOverflow پیشنهاد می کنند تهیه می کنیم. کمی بیشتر از 30
2. ما تست هایی را با یک بار معمولی برای تولید می نویسیم. برای انجام این کار، ما داده هایی را ضبط کردیم که از طریق سیستم در یک محیط تولید عبور می کند - نوعی ردیابی برای داده ها نه در شبکه، بلکه در داخل سیستم. دقیقاً از این داده ها در آزمون ها استفاده شده است.
3. با کل تیم، همه سیستم بعدی را از لیست انتخاب می‌کنند، آن را پیکربندی می‌کنند و آزمایش‌هایی را اجرا می‌کنند. این تست را نمی‌گذراند، بار را حمل نمی‌کند - آن را دور می‌اندازیم و به سراغ نفر بعدی در صف می‌رویم.
4. در سیستم هفدهم مشخص شد که همه چیز ناامید کننده است. تکان دادن بطری را متوقف کنید، وقت آن است که جدی فکر کنید.

اما این گزینه زمانی است که شما نیاز به انتخاب سیستمی دارید که در تست های از پیش آماده شده "سرعت را پشت سر بگذارد". اگر هنوز چنین تست هایی وجود نداشته باشد و بخواهید سریع انتخاب کنید چه؟

بیایید این گزینه را شبیه‌سازی کنیم (تصور این که یک توسعه‌دهنده + متوسط ​​در خلأ زندگی می‌کند، سخت است، و در زمان انتخاب هنوز ترجیح خود را در مورد اینکه کدام محصول را اول امتحان کند، رسمی نکرده است - بنابراین، استدلال بیشتر بیشتر یک نظریه‌پرداز/فلسفه/ است. در مورد یک جونیور).

پس از تصمیم گیری در مورد الزامات، بیایید شروع به انتخاب یک راه حل خارج از جعبه کنیم. چرا چرخ را دوباره اختراع کنیم: ما می رویم و یک سیستم کش آماده را می گیریم.

اگر تازه شروع کرده اید و آن را در گوگل جستجو می کنید، پس سفارش بدهید یا بگیرید، اما به طور کلی، دستورالعمل ها به این صورت خواهد بود. اول از همه با ردیس مواجه می شوید که همه جا شنیده می شود. سپس متوجه خواهید شد که EhCache قدیمی ترین و اثبات شده ترین سیستم است. در ادامه در مورد Tarantool خواهیم نوشت، یک توسعه داخلی که جنبه منحصر به فردی از راه حل دارد. و همچنین Ignite، زیرا اکنون در حال افزایش محبوبیت است و از پشتیبانی SberTech برخوردار است. در پایان نیز Hazelcast وجود دارد، زیرا در دنیای سازمانی اغلب در بین شرکت های بزرگ ظاهر می شود.

لیست کامل نیست؛ ده ها سیستم وجود دارد. و ما فقط یک چیز را خراب می کنیم. بیایید 5 سیستم منتخب را برای "مسابقه زیبایی" انتخاب کنیم و انتخاب کنیم. برنده که خواهد بود؟

Redis

آنچه آنها در وب سایت رسمی می نویسند را می خوانیم.
Redis - پروژه منبع باز ذخیره سازی اطلاعات در حافظه، قابلیت ذخیره روی دیسک، پارتیشن بندی خودکار، در دسترس بودن بالا و بازیابی از قطع شبکه را ارائه می دهد.

به نظر می رسد که همه چیز خوب است، می توانید آن را بردارید و پیچ کنید - هر چیزی که نیاز دارید، انجام می دهد. اما فقط برای سرگرمی، بیایید به سایر نامزدها نگاه کنیم.

EhCache

EhCache - "پرکاربردترین کش برای جاوا" (ترجمه شعار از وب سایت رسمی). همچنین منبع باز. و سپس متوجه می شویم که Redis برای جاوا نیست، بلکه عمومی است و برای تعامل با آن به یک wrapper نیاز دارید. و EhCache راحت تر خواهد بود. سیستم چه چیز دیگری را وعده می دهد؟ قابلیت اطمینان، اثبات شده، عملکرد کامل. خوب، آن نیز رایج ترین است. و ترابایت داده را کش می کند.

Redis فراموش شده است، من آماده انتخاب EhCache هستم.

اما حس میهن پرستی مرا وادار می کند تا ببینم چه چیزی در مورد Tarantool خوب است.

ترانتول

ترانتول - با نام "پلتفرم یکپارچه سازی داده در زمان واقعی" مطابقت دارد. این بسیار پیچیده به نظر می رسد، بنابراین ما صفحه را با جزئیات می خوانیم و عبارتی با صدای بلند پیدا می کنیم: "100٪ از داده ها را در حافظه پنهان ذخیره می کند." این باید سؤالاتی را ایجاد کند - به هر حال، داده ها می تواند بسیار بیشتر از حافظه باشد. توضیح این است که به این معنی است که Tarantool سریال سازی را برای نوشتن داده ها روی دیسک از حافظه اجرا نمی کند. در عوض، از ویژگی های سطح پایین سیستم استفاده می کند، زمانی که حافظه به سادگی به یک سیستم فایل با عملکرد ورودی/خروجی بسیار خوب نگاشت می شود. به طور کلی، آنها یک کار فوق العاده و جالب انجام دادند.

بیایید به پیاده سازی ها نگاه کنیم: بزرگراه شرکتی Mail.ru، Avito، Beeline، Megafon، Alfa-Bank، Gazprom...

اگر هنوز شکی در مورد Tarantool وجود داشت، پس پرونده پیاده سازی در Mastercard من را تمام می کند. من ترانتول میخورم

ولی به هر حال…

روشن کردن

... آیا موارد دیگری وجود دارد روشن کردن، به عنوان یک "پلتفرم محاسباتی درون حافظه... سرعت های درون حافظه روی پتابایت داده" نامگذاری شده است. همچنین مزایای زیادی در اینجا وجود دارد: حافظه پنهان توزیع شده در حافظه، سریعترین ذخیره سازی و حافظه پنهان کلید با ارزش، مقیاس بندی افقی، در دسترس بودن بالا، یکپارچگی دقیق. به طور کلی، معلوم می شود که سریع ترین Ignite است.

پیاده سازی ها: Sberbank، American Airlines، Yahoo! ژاپن. و سپس متوجه شدم که Ignite فقط در Sberbank پیاده سازی نشده است، بلکه تیم SberTech افراد خود را به تیم Ignite می فرستد تا محصول را اصلاح کنند. این کاملاً فریبنده است و من آماده مصرف Ignite هستم.

کاملاً مشخص نیست چرا، من به نکته پنجم نگاه می کنم.

فندقی

میرم تو سایت فندقی، خواندن و به نظر می رسد که سریع ترین راه حل برای کش توزیع شده Hazelcast است. این دستور العمل سریعتر از همه راه حل های دیگر است و به طور کلی در زمینه شبکه داده های درون حافظه پیشرو است. در این زمینه، گرفتن چیز دیگری به معنای احترام گذاشتن به خود نیست. همچنین از ذخیره‌سازی اطلاعات اضافی برای عملکرد مستمر خوشه بدون از دست دادن داده استفاده می‌کند.

تمام شد، من حاضرم Hazelcast را بگیرم.

مقایسه

اما اگر نگاه کنید، هر پنج نامزد به گونه ای توصیف شده اند که هر کدام از آنها بهترین هستند. چگونه انتخاب کنیم؟ ما می توانیم ببینیم کدام یک محبوب ترین است، به دنبال مقایسه باشیم و سردرد از بین می رود.

ما یکی مثل این را پیدا می کنیم مروری، 5 سیستم ما را انتخاب کنید.

در اینجا آنها مرتب شده اند: Redis در صدر است، Hazelcast در رتبه دوم قرار دارد، Tarantool و Ignite در حال افزایش محبوبیت هستند، EhCache به همان شکل بوده و باقی می ماند.

اما بیایید نگاه کنیم روش محاسبه: پیوند به وب سایت ها، علاقه عمومی به سیستم، پیشنهادات شغلی - عالی! یعنی وقتی سیستم من از کار بیفتد، می گویم: "نه، قابل اعتماد است! پیشنهادهای کاری زیادی وجود دارد..." چنین مقایسه ساده ای انجام نخواهد داد.

همه این سیستم ها فقط سیستم های کش نیستند. آنها همچنین عملکردهای زیادی دارند، از جمله زمانی که داده ها برای پردازش به مشتری پمپ نمی شوند، اما برعکس: کدی که باید روی داده ها اجرا شود به سرور منتقل می شود، در آنجا اجرا می شود و نتیجه برگردانده می شود. و اغلب آنها به عنوان یک سیستم جداگانه برای ذخیره سازی در نظر گرفته نمی شوند.

خوب، بیایید تسلیم نشویم، بیایید مقایسه مستقیمی از سیستم ها پیدا کنیم. بیایید دو گزینه برتر را در نظر بگیریم - Redis و Hazelcast. ما به سرعت علاقه مندیم و آنها را بر اساس این پارامتر مقایسه خواهیم کرد.

هرتز در مقابل ردیس

ما این را پیدا می کنیم مقایسه:


آبی Redis است، قرمز رنگ Hazelcast است. Hazelcast در همه جا برنده است، و دلیلی برای این وجود دارد: چند رشته ای است، بسیار بهینه شده است، هر رشته با پارتیشن خود کار می کند، بنابراین هیچ مسدودی وجود ندارد. و Redis تک رشته ای است؛ از CPU های چند هسته ای مدرن بهره نمی برد. Hazelcast دارای I/O ناهمزمان است، Redis-Jedis دارای سوکت های مسدود کننده است. از این گذشته، Hazelcast از یک پروتکل باینری استفاده می کند و Redis متن محور است، یعنی ناکارآمد است.

در هر صورت، اجازه دهید به منبع دیگری برای مقایسه بپردازیم. او چه چیزی را به ما نشان خواهد داد؟

ردیس در مقابل هرتز

یکی دیگر مقایسه:


در اینجا، برعکس، قرمز Redis است. یعنی Redis از نظر عملکرد بهتر از Hazelcast است. Hazelcast برنده مقایسه اول شد، Redis برنده دوم شد. اینجا خیلی دقیق توضیح داد که چرا Hazelcast در مقایسه قبلی برنده شد.

به نظر می رسد که نتیجه اولین مورد در واقع تقلب شده است: Redis در جعبه پایه گرفته شده است و Hazelcast برای یک مورد آزمایشی طراحی شده است. سپس معلوم می شود: اولاً، ما نمی توانیم به کسی اعتماد کنیم، و ثانیاً، هنگامی که در نهایت یک سیستم را انتخاب می کنیم، هنوز باید آن را به درستی پیکربندی کنیم. این تنظیمات شامل ده ها، تقریبا صدها پارامتر است.

تکان دادن بطری

و من می توانم کل فرآیندی را که اکنون انجام داده ایم با استعاره زیر توضیح دهم: "تکان دادن بطری". یعنی اکنون نیازی به برنامه ریزی ندارید، اکنون نکته اصلی این است که بتوانید stackoverflow را بخوانید. و من یک نفر را در تیمم دارم، یک حرفه ای که دقیقاً در لحظات حساس اینگونه کار می کند.

داره چیکار میکنه؟ او یک چیز شکسته را می بیند، یک ردپای پشته را می بیند، چند کلمه از آن می گیرد (که تخصص او در برنامه است)، در گوگل جستجو می کند، در میان پاسخ ها stackoverflow را پیدا می کند. بدون خواندن، بدون فکر کردن، از میان پاسخ‌های سؤال، چیزی شبیه به جمله «این و آن را بکن» انتخاب می‌کند (انتخاب چنین پاسخی استعداد اوست، زیرا همیشه این پاسخ بیشترین لایک را دریافت نمی‌کند). اعمال می شود، به نظر می رسد: اگر چیزی تغییر کرده باشد، عالی است. اگر تغییر نکرده است، آن را برگردانید. و راه اندازی-بررسی-جستجو را تکرار کنید. و به این روش شهودی، اطمینان حاصل می کند که کد پس از مدتی کار می کند. نمی داند چرا، نمی داند چه کرده است، نمی تواند توضیح دهد. ولی! این عفونت کار می کند. و "آتش خاموش شد." حالا بیایید بفهمیم که چه کار کردیم. هنگامی که برنامه کار می کند، مرتبه ای آسان تر است. و باعث صرفه جویی در زمان می شود.

این روش با این مثال به خوبی توضیح داده شده است.

زمانی جمع آوری قایق بادبانی در بطری بسیار محبوب بود. در عین حال، قایق بادبانی بزرگ و شکننده است و گردن بطری بسیار باریک است، فشار دادن آن به داخل غیرممکن است. چگونه آن را مونتاژ کنیم؟

چنین روشی وجود دارد، بسیار سریع و بسیار مؤثر.

کشتی از یک دسته چیزهای کوچک تشکیل شده است: چوب، طناب، بادبان، چسب. همه اینها را در یک بطری می ریزیم.
با دو دست بطری را می گیریم و شروع به تکان می کنیم. تکانش می دهیم و تکانش می دهیم. و معمولاً معلوم می شود که زباله کامل است. اما گاهی اوقات. گاهی معلوم می شود که یک کشتی است! به طور دقیق تر، چیزی شبیه به یک کشتی.

ما این چیزی را به کسی نشان می دهیم: "سریوگا، می بینی!" و در واقع، از دور شبیه یک کشتی است. اما نمی توان اجازه داد این روند ادامه پیدا کند.

راه دیگری هم وجود دارد. آنها توسط افراد پیشرفته تر مانند هکرها استفاده می شوند.

من به این آقا وظیفه دادم، او همه کارها را انجام داد و رفت. و شما نگاه می کنید - به نظر می رسد این کار تمام شده است. و بعد از مدتی، زمانی که کد باید نهایی شود، این به خاطر او شروع می شود ... خوب است که او قبلاً موفق شده است از آنجا فرار کند. اینها بچه هایی هستند که با استفاده از مثال یک بطری، این کار را انجام می دهند: می بینید، جایی که ته آن است، شیشه خم می شود. و کاملاً مشخص نیست که شفاف است یا خیر. سپس «هکرها» این ته را قطع می‌کنند، یک کشتی را در آنجا قرار می‌دهند، سپس دوباره قسمت پایینی را می‌چسبانند، و انگار قرار است اینطور باشد.

از نقطه نظر تنظیم مشکل، همه چیز درست به نظر می رسد. اما با استفاده از کشتی ها به عنوان مثال: اصلاً چرا این کشتی را بسازید، به هر حال چه کسی به آن نیاز دارد؟ هیچ عملکردی ارائه نمی دهد. معمولاً چنین کشتی هایی به افراد بسیار عالی هدایایی می دهند که آن را به عنوان نوعی نماد و به عنوان علامت در قفسه ای بالای خود قرار می دهند. و اگر چنین شخصی، رئیس یک تجارت بزرگ یا یک مقام عالی رتبه، چگونه پرچم برای چنین هکی که گردنش بریده شده است، ایستاده است؟ بهتر است هرگز از آن خبر نداشته باشد. بنابراین، چگونه آنها در نهایت این کشتی‌ها را می‌سازند که می‌توان آن‌ها را به یک شخص مهم داد؟

تنها مکان کلیدی که واقعا نمی توانید در مورد آن کاری انجام دهید، بدن است. و بدنه کشتی درست در گردن قرار می گیرد. در حالی که کشتی خارج از بطری مونتاژ می شود. اما این فقط مونتاژ یک کشتی نیست، بلکه یک هنر جواهرسازی واقعی است. اهرم های ویژه ای به قطعات اضافه می شود که سپس به آنها اجازه بلند شدن می دهد. به عنوان مثال بادبان ها را تا می کنند، با احتیاط داخل می کنند و سپس با کمک موچین، بسیار دقیق و با دقت بالا کشیده می شوند. نتیجه یک اثر هنری است که می توان با وجدان و غرور آرام به آن هدیه داد.

و اگر بخواهیم پروژه موفق باشد، باید حداقل یک جواهرساز در تیم حضور داشته باشد. کسی که به کیفیت محصول اهمیت می‌دهد و همه جوانب را در نظر می‌گیرد، بدون اینکه چیزی را از دست بدهد، حتی در لحظات استرس، زمانی که شرایط ایجاب می‌کند که به هزینه‌های مهم، کار فوری را انجام دهد. تمام پروژه های موفقی که پایدار هستند و در آزمون زمان ایستاده اند، بر اساس این اصل ساخته شده اند. چیزی بسیار دقیق و منحصر به فرد در آنها وجود دارد، چیزی که از همه امکانات موجود بهره می برد. در مثال با کشتی در بطری، این واقعیت که بدنه کشتی از گردن عبور می کند، مشخص می شود.

با بازگشت به وظیفه انتخاب سرور حافظه پنهان، این روش چگونه ممکن است اعمال شود؟ من این گزینه را برای انتخاب از بین تمام سیستم های موجود ارائه می دهم - بطری را تکان ندهید، انتخاب نکنید، اما به آنچه که در اصل دارند نگاه کنید، هنگام انتخاب یک سیستم به دنبال چه چیزی باشید.

کجا به دنبال بطری گردن بگردیم

بیایید سعی کنیم بطری را تکان ندهیم، از همه چیزهایی که در آنجا هست یکی یکی عبور نکنیم، اما ببینیم اگر ناگهان، برای وظیفه خود، چنین سیستمی را خودمان طراحی کنیم، چه مشکلاتی پیش خواهد آمد. البته، ما دوچرخه را مونتاژ نمی کنیم، اما از این نمودار استفاده می کنیم تا به ما کمک کند بفهمیم به چه نکاتی باید در توضیحات محصول توجه کنیم. بیایید چنین نموداری را ترسیم کنیم.

اگر سیستم توزیع شده باشد، چندین سرور خواهیم داشت (6). فرض کنید چهار عدد وجود دارد (قرار دادن آنها در تصویر راحت است، اما، البته، می تواند به تعداد دلخواه شما وجود داشته باشد). اگر سرورها روی گره‌های مختلف هستند، به این معنی است که همه آنها کدی را اجرا می‌کنند که وظیفه آن اطمینان از تشکیل یک خوشه و در صورت شکست، اتصال و شناسایی یکدیگر است.

ما همچنین به منطق کد (2) نیاز داریم که در واقع مربوط به ذخیره سازی است. کلاینت ها از طریق برخی API با این کد تعامل دارند. کد کلاینت (1) می تواند در همان JVM باشد یا از طریق شبکه به آن دسترسی داشته باشد. منطق پیاده سازی شده در داخل، تصمیم گیری است که کدام اشیاء را در حافظه پنهان بگذاریم و کدام را خارج کنیم. ما از حافظه (3) برای ذخیره کش استفاده می کنیم، اما در صورت لزوم، می توانیم برخی از داده ها را روی دیسک (4) ذخیره کنیم.

بیایید ببینیم بار در کدام قسمت ها رخ می دهد. در واقع، هر فلش و هر گره بارگذاری می شود. اولاً، بین کد مشتری و api، اگر این ارتباط شبکه باشد، فرونشست می‌تواند کاملاً محسوس باشد. ثانیا، در چارچوب خود api - اگر با منطق پیچیده زیاده روی کنیم، می توانیم با CPU به مشکل برسیم. و اگر منطق زمان را برای حافظه تلف نکند خوب خواهد بود. و تعامل با سیستم فایل باقی می ماند - در نسخه معمول این سریال سازی / بازیابی و نوشتن / خواندن است.

بعدی تعامل با خوشه است. به احتمال زیاد، در همان سیستم خواهد بود، اما می تواند جداگانه باشد. در اینجا باید انتقال داده ها به آن، سرعت سریال سازی داده ها و تعاملات بین خوشه را نیز در نظر بگیرید.

حال از یک طرف می‌توانیم تصور کنیم که «چه چرخ‌دنده‌ها» در سیستم کش در هنگام پردازش درخواست‌های کد ما می‌چرخد و از طرف دیگر می‌توانیم تخمین بزنیم که کد ما چه درخواست‌هایی را برای این سیستم ایجاد می‌کند. این برای انتخاب کمابیش هوشیارانه کافی است - سیستمی را برای مورد استفاده خود انتخاب کنیم.

فندقی

بیایید ببینیم چگونه این تجزیه را در لیست خود اعمال کنیم. به عنوان مثال، Hazelcast.

به منظور قرار دادن/گرفتن داده ها از Hazelcast، کد مشتری به (1) api دسترسی پیدا می کند. هرتز به شما این امکان را می دهد که سرور را به صورت تعبیه شده اجرا کنید و در این حالت دسترسی به api یک فراخوانی متد در داخل JVM است که می توان آن را رایگان در نظر گرفت.

برای اینکه منطق در (2) کار کند، هرتز به هش آرایه بایت کلید سریالی تکیه می کند - یعنی در هر صورت کلید سریالی می شود. این سربار برای هرتز اجتناب ناپذیر است.
استراتژی های اخراج به خوبی اجرا می شوند، اما برای موارد خاص می توانید استراتژی خود را اضافه کنید. لازم نیست نگران این قسمت باشید.

ذخیره سازی (4) را می توان متصل کرد. عالی. تعامل (5) برای تعبیه شده را می توان فوری در نظر گرفت. تبادل داده بین گره ها در خوشه (6) - بله، وجود دارد. این سرمایه گذاری در تحمل خطا به قیمت بهای سرعت است. ویژگی هرتز Near-cache به شما امکان می دهد قیمت را کاهش دهید - داده های دریافتی از سایر گره ها در خوشه ذخیره می شوند.

در چنین شرایطی برای افزایش سرعت چه می توان کرد؟

به عنوان مثال، برای جلوگیری از سریال سازی کلید در (2) - حافظه پنهان دیگری را در بالای Hazelcast وصل کنید تا داغ ترین داده ها را دریافت کنید. ورزش مستر کافئین را برای این منظور انتخاب کرد.

برای چرخاندن در سطح (6)، هرتز دو نوع ذخیره سازی ارائه می دهد: IMap و ReplicatedMap.


شایان ذکر است که Hazelcast چگونه وارد مجموعه فناوری Sportmaster شد.

در سال 2012، زمانی که ما روی اولین آزمایشی سایت آینده کار می کردیم، اولین لینکی بود که موتور جستجو بازگرداند، Hazelcast بود. آشنایی "اولین بار" شروع شد - ما مجذوب این واقعیت شدیم که فقط دو ساعت بعد ، وقتی هرتز را به سیستم پیچ کردیم ، کار کرد. و خوب کار کرد. در پایان روز تعدادی آزمایش را تکمیل کرده بودیم و خوشحال بودیم. و این ذخیره نیرو برای غلبه بر شگفتی هایی که هرتز به مرور زمان ایجاد کرد کافی بود. حالا تیم Sportmaster دلیلی برای کنار گذاشتن Hazelcast ندارد.

اما استدلال هایی مانند "اولین پیوند در موتور جستجو" و "HelloWorld به سرعت جمع آوری شد"، البته، یک استثنا و یکی از ویژگی های لحظه ای است که در آن انتخاب انجام شد. آزمایشات واقعی برای سیستم انتخاب شده با عرضه به مرحله تولید آغاز می شود و در این مرحله است که هنگام انتخاب هر سیستمی از جمله کش باید به آن توجه کنید. در واقع، در مورد ما می توان گفت که ما به طور تصادفی Hazelcast را انتخاب کردیم، اما بعد معلوم شد که ما درست انتخاب کردیم.

برای تولید، بسیار مهمتر است: نظارت، مدیریت خرابی در گره های جداگانه، تکرار داده ها، هزینه مقیاس گذاری. یعنی ارزش توجه به وظایفی را دارد که در حین تعمیر و نگهداری سیستم ایجاد می شود - زمانی که بار ده ها برابر بیشتر از برنامه ریزی شده است، زمانی که به طور تصادفی چیزی را در مکان اشتباه آپلود می کنیم، زمانی که باید نسخه جدیدی را عرضه کنیم. از کد، داده ها را جایگزین کنید و آن را بدون توجه به مشتریان انجام دهید.

برای همه این الزامات، Hazelcast مطمئناً مناسب است.

ادامه دارد

اما هازلکست نوشدارویی نیست. در سال 2017، ما Hazelcast را برای کش مدیریت انتخاب کردیم، صرفاً بر اساس برداشت های خوب از تجربیات گذشته. این نقش کلیدی در یک شوخی بسیار بی رحمانه داشت که به همین دلیل ما خود را در شرایط سختی دیدیم و به مدت 60 روز "قهرمانانه" از آن خارج شدیم. اما بیشتر در مورد آن در قسمت بعدی.

در ضمن... کد جدید مبارک!

منبع: www.habr.com