بخش سوم و آخر سیستم دیزاین درمورد کش و سی دی ان و صف نوشتم، مطالب قبلی رو هم میتونید از لینک های زیر بخونید:
پست اول:
https://vrgl.ir/S0YQ1
پست دوم:
https://vrgl.ir/wDJE5
تو دوتا بخش قبلی درموردموارد زیر صحبت کردم:
-راه اندازی با یک سرور (Single server setup)
-انتخاب پایگاه داده مناسب
-توزیع کننده بار (Load balancer)
-ارتقاء یا اسکیل (scale) عمودی در مقابل افقی
-پایگاه داده تکثیر پذیر Database replication
وبسایت پر سرعت با کش (Cache) ، راز پشت لود سریع صفحات:
کش، یک فضای ذخیره‌سازی موقته که نتایج خروجی‌های پرهزینه یا داده‌های پرکاربرد رو در حافظه نگه میداره تا درخواست‌های بعدی سریع‌تر پاسخ داده بشن.
همینطور که تو شکل بالا می‌بینید، هر بار که یک صفحه وب جدید بارگذاری میشه، برای دریافت داده، یک یا چند دستور به بانک اطلاعاتی ارسال میشه. فراخوانی مکرر بانک اطلاعاتی، عملکرد کلی برنامه روتحت تاثیر قرار میده. کش می‌تونه این مشکل رو تا حد زیادی برطرف کنه.
لایه کش
کش، یک لایه ذخیره‌سازی موقت دادست که بسیار سریع‌تر از بانک اطلاعاتی عمل میکنه.
مزایای داشتن یک لایه کش مجزا :
عملکرد بهتر سیستم: با کاهش بار روی بانک اطلاعاتی، سرعت کلی سیستم بهبود پیدا میکنه.
کاهش حجم کاری بانک اطلاعاتی: فراخوانی‌های مکرر به بانک اطلاعاتی کاهش پیدا میکنه.
مقیاس‌پذیری مستقل: امکان افزایش ظرفیت کش به صورت مجزا از سایر اجزای سیستم وجود داره.
نکاتی برای استفاده از کش:
در نظر گرفتن نکات زیر برای استفاده از یه سیستم کش ضروریه:
زمان مناسب برای استفاده از کش: زمانی از کش استفاده کنید که داده‌ها به طور مکرر خوانده میشن اما به ندرت تغییر میکنن. حافظه کش، فرّاره (فرار میکنه 😅 )؛ بنابراین برای ذخیره‌سازی دائمی داده‌ها مناسب نیست. به عنوان مثال، با راه‌اندازی مجدد (reset) سرور کش، تمام داده‌های موجود در حافظه از بین میره یا همون پاک میشه خودمون. پس داده‌های مهم رو باید در مخازن داده دائمی (Database) ذخیره کرد.
پ.ن: "عجم زنده کردم بدین پارسی ... ، چه اصطلاحی "پس داده‌های مهم رو باید در مخازن داده دائمی ذخیره کرد" خودم کفم بریده، یکی از سخترین کارا ترجمه متنای تخصصیه و سعی میکنم فارسی و انگلیسی مفهوم رو برسونم ولی اگه مشکلی بود حتما بهم گوشزد کنید.
سیاست انقضا (Expiration Policy): ایجاد یک سیاست انقضا برای داده‌های کش‌شده، امری ضروریه. بعد از منقضی شدن داده‌های کش‌شده، اونها از کش حذف میشن. نبودِ سیاست انقضا باعث میشه داده‌ها برای همیشه در حافظه باقی بمونن. تنظیم زمان انقضای خیلی کوتاه، باعث بارگذاری مجدد و مکرر داده‌ها از بانک اطلاعاتی میشه. از طرف دیگه، زمان انقضای خیلی طولانی نیز باعث قدیمی یا کهنه شدن داده‌ها میشه که باید بالانس مناسب بین این دوتارو پیدا کرد.
سازگاری (Consistency): این مورد به همگام یا یکپارچه (sync) نگهداشتن بانک اطلاعات و کش اشاره داره. ناسازگاری می‌تونه به دلیل عدم انجام عملیات تغییر داده روی بانک اطلاعاتی و کش در یک تراکنش واحد رخ داده باشه. حفظ سازگاری بین بانک اطلاعاتی و کش در هنگام اسکیل کردن در چندین منطقه، چالش‌برانگیزه.انتخاب روش مناسب برای حفظ یکپارچگی در لایه کش بستگی به نیازهای خاص برنامه، میزان خواندن و نوشتن داده‌ها، و تحمل‌پذیری برنامه برای تأخیر داره. روش‌های مختلفی برای پیاده‌سازی این یکپارچگی وجود داره که هر کدام مزایا و معایب خاص خودشون رو دارن. مهمه که با توجه به نیازهای خاص سیستم، روش مناسب انتخاب و پیاده‌سازی بشه تا بهترین عملکرد و اطمینان از یکپارچگی داده‌ها حاصل بشه. درمورد consistency خودتون حتما تحقیق کنید و مطلب بخونید خیلی مبحث بزرگیه خودش.
کاهش اثرات خرابی: یک سرور کش به تنهایی می‌تونه یک نقطه شکست بالقوه (SPOF) باشه. SPOF به وضعیتی گفته می‌شود که خرابی یک جزء از سیستم، کل سیستم را از کار می‌اندازد. برای جلوگیری از SPOF، استفاده از چندین سرور کش در مراکز داده مختلف توصیه میشه. همچنین، اختصاص مازاد حافظه نیز رویکرد مفیدیه؛ چون با افزایش مصرف حافظه، بافری برای سیستم در نظر گرفته میشه.مانیتورینگ مداوم سرورها برای تشخیص خرابی‌ها و انجام اقدامات بازیابی خودکار می‌تونه به کاهش اثرات خرابی کمک کنه.
*(Single Point of Failure - SPOF)
وبسایت پر سرعت با CDN و توزیع محتوا: تحویل سریع‌تر فایل‌های حجیم!
در بخش قبلی با مفهوم کش (Cache) آشنا شدیم. در این بخش به سراغ مفهوم دیگه‌ای به نام شبکه توزیع محتوا (Content Delivery Network - CDN) میریم.
توی این کتاب در مورد نحوه استفاده از CDN برای کش کردن محتوای استاتیک تمرکز داره و کش کردن محتوای پویا (دینامیک) رو پوشش نمیده.
به صورت کلی، نحوه عملکرد CDN به این شکله که وقتی کاربری از وبسایت بازدید میکنه، نزدیک‌ترین سرور CDN به کاربر، محتوای استاتیک رو تحویل میده. به طور شهودی، هرچه کاربران از سرورهای CDN دورتر باشن، وبسایت با سرعت کمتری بارگذاری میشه. برای مثال، اگر سرورهای CDN در سان‌فرانسیسکو باشن، کاربران لس‌آنجلس محتوای وبسایت رو سریع‌تر از کاربران اروپا دریافت میکنن. شکل زیر خیلی خوب نشون میده که CDN چطور زمان بارگذاری رو بهبود می‌بخشه.
گردش کار (ورک فلو workflow) در CDN :
1- کاربر A با استفاده از یک URL تصویر سعی میکنه به image.png دسترسی پیدا کنه. دامنه‌ی URL توسط ارائه‌دهنده‌ی CDN تأمین میشه.
2- اگر سرور CDN تصویر image.png رو تو کش نداشته باشه، سرور CDN فایل رو از مبدا (Origin) درخواست میکنه که می‌تونه یک وب‌سرور یا فضای ذخیره‌سازی آنلاین مانند Amazon S3 باشه.
3- مبدا، image.png رو به سرور CDN برمی‌گردونه که شامل هدر اختیاری HTTP به نام Time-to-Live (TTL) که مدت زمان کش شدن تصویر رو مشخص میکنه.
4- سی دی ان (CDN) تصویر رو کش میکنه و اون رو به کاربر A برمی‌گردونه. این تصویر تا وقتی که TTL منقضی نشه، تو CDN که کش شده نگه میداره.
5- کاربر B درخواستی برای دریافت همون تصویر ارسال میکنه.
6- تا وقتی که TTL منقضی نشده باشه، تصویر از کش برای کاربر ارسال میشه.
نکاتی برای استفاده از CDN
هزینه: CDNها توسط ارائه‌دهندگان شخص ثالث (third-party providers) اداره میشن و شما برای انتقال داده‌ها به داخل و خارج از CDN هزینه پرداخت می‌کنید. کش کردن دیتاهایی که به ندرت استفاده‌شده، مزایای قابل توجهی نداره، بنابراین باید از انتقال آن‌ها به CDN صرف نظر کنید.
تنظیم زمان انقضای کش مناسب: برای محتوای حساس به زمان، تعیین زمان انقضای کش بسیار مهمه. زمان انقضای کش نباید خیلی طولانی و نه خیلی کوتاه باشه. اگر خیلی طولانی باشه، ممکنه محتوا دیگه به‌روز نباشه. اگر خیلی کوتاه باشه، می‌تونه باعث بارگذاری مجدد مکرر محتوا از سرورهای اصلی به CDN باشه.
پشتیبان‌گیری CDN: باید در نظر بگیرید که وبسایت یا اپلیکیشن شما چطور با خرابی CDN مقابله میکنه. اگر قطعی موقت CDN رخ بده، کاربران باید بتونن مشکل رو تشخیص بدن و منابع را از مبدا یا سرور درخواست کنن.
ابطال کردن فایل‌ها: میتونید با انجام یکی از عملیات زیر، یه فایل رو قبل از انقضا از CDN حذف کنید، برای ابطال کردن شیء CDN میتونید از APIهایی که توسط فروشندگان CND ارائه میشه استفاده کنید.
استفاده از نسخه‌بندی شیء برای ارائه نسخه متفاوتی از شیء: برای نسخه‌بندی یک شیء، میتونید پارامتری رو به URL اضافه کنید، مثل شماره‌ی نسخه. برای مثال، شماره‌ی نسخه‌ی ۲ به رشته‌ی کوئری اضافه میشه: image.png?v=2.
شکل زیر طرحی رو نشون میده که CDN و کش به اون اضافه شده .
صف پیام، قهرمان پشت صحنه وبسایت‌های پرطرفدار!
فرض کنید دارید یه وبسایت خیلی پرطرفدار رو اجرا می‌کنین. کلی کاربر داره ازش استفاده میکنه و هر کدوم درخواست‌های مختلفی دارن. خب، چطوری میشه با این حجم از درخواست‌ها به طور روان و بدون مشکل برخورد کرد؟ اینجا یه قهرمان پنهانی به اسم “صف پیام” (Message Queue) به دادمون می‌رسه.
صف یه بافره که درخواست‌های کاربرها رو به ترتیب توی خودش نگه میداره و بعد به قسمت‌های مختلف وبسایت که مسئول رسیدگی به اون درخواست‌ها هستن، ارسال میکنه. اینطوری، هیچکدوم از قسمت‌ها زیر بار درخواست‌ها له نمی‌شن و همه چیز آروم و روان پیش میره.
مثال: فرض کنید یه اپلیکیشن برای ادیت عکس دارین که می‌تونه عکس‌ها رو برش بزنه، نورشون رو تنظیم کنه و خلاصه کلی کارای دیگه روش انجام بده. خب، این کارا زمان‌بر هستن. با صف، وقتی کاربر درخواست ادیت عکس میده، اون درخواست توی صف پیام قرار می‌گیره. یه قسمت دیگه که مسئول ادیت عکسه، کم‌کم سراغ صف پیام میره و درخواست‌ها رو برمی‌داره و ادیت میکنه. حتی اگه سرور کاربر برای مدتی قطع بشه، اشکالی نداره چون درخواستش توی صف مونده و بعدا رسیدگی میشه.
خداحافظ ارور، سلام سرحال بودن!
هر سایتی که بزرگ میشه، با یه سری دردسرهای جدید روبرو میشه. لازمه که حواسمون باشه وبسایت همیشه سرپا و سرحال باشه. چند تا ابزار بهمون در این زمینه کمک میکنن:
لاگ‌گیری (Logging): با این کار می‌تونیم بفهمیم چه خطاهایی توی سایت افتاده و سریع‌تر رفعشون کنیم.
مانیتورینگ (Monitoring): یعنی اینکه حواسمون باشه همه چی داره خوب کار میکنه. مثلا اینکه چقدر فضا روی سرور مونده، چقدر حافظه داره استفاده میشه و… .
اتوماسیون (Automation): بعضی کارها رو می‌تونیم به صورت اتوماتیک انجام بدیم. مثلا هر وقت یه نفر کد جدید می‌نویسه، اتوماتیک چک بشه که مشکلی نداشته باشه. اینطوری خیالمون راحت‌تره و دیگه لازم نیست همه چی رو دستی چک کنیم . برای این مورد ci/cd رو هم پیشنهاد میدم که درموردش بخونید.
زیرساخت برای میلیونها کاربر!
تبریک! تا اینجا تونستی یه وبسایت حسابی راه بندازی و کلی کاربر جذب کنی. ولی حالا می‌خوای اون رو تبدیل به یه ابرقدرت کنی، درسته؟ خب، برای اینکه بتونی از پس میلیونها کاربر بربیای باید زیرساخت‌شو تقویت کنی.
تقویت کردن یه سیستم یه پروسه مرحله به مرحله‌ست. همه‌ی اون چیزایی که تو این سه تا پست یاد گرفتی می‌تونه تا یه جایی کارتو راه بندازه، ولی اگه می‌خوای با جمعیت میلیونی کاربرا کنار بیای، باید یه کم ظریف‌کاری کنی و از استراتژی‌های جدیدتری استفاده کنی. مثلا شاید لازم باشه کل سیستم رو بهینه کنی و اون رو به بخش‌های کوچیک‌تر و مستقل‌تری تقسیم کنی.
اما نگران نباش! همه‌ی اینایی که یاد گرفتی یه زیربنای محکم بهت میدن تا با چالش‌های جدید مقابله کنی. حالا بریم سراغ یه خلاصه از کارهایی که باید انجام بدی تا بتونی از پس میلیونها کاربر بربیای:
خداحافظ پیچیدگی، سلام سادگی! لایه وب رو بدون حالت (stateless) نگه دار. یعنی اطلاعات مربوط به کاربرها رو اونجا ذخیره نکن. اینطوری همه چیز ساده‌تر و سریع‌تر میشه.
همه جا رو پشتیبان‌گیری کن! تو هر بخش از وبسایتت، یه سیستم پشتیبان (redundancy) داشته باش. اینطوری اگه یه قسمتی از کار افتاد، کل سایت از کار نمی‌افته.
هر چی می‌تونی رو کش کن! یه فضای ذخیره‌سازی موقت (cache) داشته باش تا نتایج پرکاربرد رو ذخیره کنی. اینطوری دیگه لازم نیست هر بار دوباره همون کارا رو انجام بدی و همه چیز سریع‌تر پیش میره.
بذار دیتاسنترهای بیشتری واست کار کنن! از چند تا مرکز داده (data center) تو نقاط مختلف دنیا استفاده کن. اینطوری اگه یه مرکز با مشکل روبرو بشه، بقیه میتونن کار رو انجام بدن و کاربرها اذیت نمی‌شن.
فایل‌های ثابت رو بسپار به CDN! از یه شبکه توزیع محتوا (CDN) برای تحویل سریع‌تر فایل‌های حجیم و بدون تغییر به کاربرها استفاده کن.
بانک اطلاعاتی رو تیکه تیکه کن! بانک اطلاعاتی رو به بخش‌های کوچیک‌تر و قابل مدیریت‌تری به اسم Shard تقسیم کن. اینطوری دیگه همه چی روی یه سرور سنگینی نمی‌کنه.
سیستم رو خرد کن تا قوی‌تر بشه! لایه‌های مختلف سیستم رو به سرویس‌های مجزا تقسیم کن. اینطوری هر کدوم رو می‌تونی جداگانه ارتقا بدی و نگهداریشون هم راحت‌تره.
حواست به همه چی باشه! سیستم رو زیر نظر داشته باش (monitor) و از ابزارهای اتوماسیون استفاده کن تا کارها به صورت خودکار انجام بشه. اینطوری خیالت راحت‌تره و می‌تونی تمرکزت رو روی چیزای مهم‌تر بذاری.
