وب و سیستم های توزیع شده اغلب می توانند در ترافیک غرق شوند.

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

فهرست مطالب

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

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

راه های مقابله با بارهای ترافیکی بالا

بازگشت نمایی و تلاش مجدد

خلاصه

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

ترافیک در سیستم های توزیع شده به طور کلی به تبادل داده بین کاربران نهایی و نقطه ورود به سیستمی که ممکن است به اجزای توزیع شده متکی باشد اشاره دارد.

الگوهای ترافیکی که یک سیستم می بیند معمولاً تصمیمات چندگانه طراحی را تحت تأثیر قرار می دهد زیرا بر عملکرد، مقیاس پذیری و قابلیت اطمینان یک سیستم تأثیر می گذارد.

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

موج‌های ترافیکی اغلب می‌توانند سیستم‌هایی را که برای مقابله با آن‌ها مجهز نیستند فلج کنند.

ممکن است با مواردی مواجه شده باشید که سرویس‌های رسانه‌های اجتماعی مانند اینستاگرام یا TikTok از کار افتاده است. در برخی موارد، این ممکن است به دلیل افزایش ترافیک باشد.

در اینجا برخی از مشکلات رایج وجود دارد که افزایش ترافیک ممکن است ایجاد کند:

ازدحام : با افزایش ترافیک، ازدحام شبکه ممکن است افزایش یابد. این ممکن است در برخی موارد منجر به از دست دادن بسته ها، افزایش تاخیر و تاثیر عملکرد سیستم ها شود.

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

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

راه های مقابله با بارهای پر ترافیک

هیچ سیستمی از خرابی تحت حجم نامشخص ترافیک مصون نیست.

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

اکنون، بیایید برخی از راه حل های رایج را که می توانند به مقابله با افزایش ترافیک کمک کنند، پوشش دهیم.

اولاً، مقیاس افقی به طور کلی فرآیند اضافه کردن منابع به یک سیستم با گفت ن منابع بیشتر به صورت موازی است. به عنوان مثال، گفت ن سرورهای بیشتر یا اضافه کردن گره های CDN بیشتر.

در واقع، به جای افزایش ظرفیت یک گره در شبکه، منابع بیشتری را اضافه می کند.

توزیع ترافیک بین سرورها می تواند منجر به بهبود عملکرد، تاخیر کمتر و به طور کلی بهبود زمان پاسخگویی شود.

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

متعادل‌کننده‌های بار می‌توانند به‌طور هوشمندانه درخواست‌ها را به سرورها هدایت کنند تا ترافیک بین سیستم‌ها به خوبی متعادل شود و یک سیستم خاص را تحت تأثیر قرار ندهد.

علاوه بر این، کش کردن می‌تواند به طور چشمگیری نیاز به ترافیک (درخواست‌ها) برای رسیدن به یک سرور را کاهش دهد. برخی از انواع درخواست ها، مانند آنهایی که به محتوای ثابت به عنوان کاندیدای عالی برای ذخیره سازی دسترسی دارند.

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

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

این سناریویی است که در آن چندین مشتری (یکی اصلی و دیگری پایین‌دستی) ممکن است درخواست‌های خود را دوباره امتحان کنند و در نتیجه، یک سیستم پایین‌دست ممکن است با درخواست‌ها غرق شود و این خود به خود منجر به شکست‌های آبشاری شود.

در شکل بالا می بینیم که دو درخواست از سرور (یک بار امتحان مجدد در صورت خرابی در صف)، منجر به:

1) چهار درخواست از مؤلفه بدون سرور به موضوع اعلان (دو درخواست برای مؤلفه بدون سرور و دو تلاش مجدد)

2) هشت درخواست از موضوع اطلاع رسانی به صف (چهار درخواست به صف، چهار بار مجدد).

حتی یک شکست واحد در مولفه پایانی (در این مورد صف)، منجر به تعداد تصاعدی درخواست‌های مجدد برای آن شد.

یک پادزهر رایج برای این مشکل، استفاده از عقب‌نشینی نمایی در حین تلاش مجدد درخواست‌ها است.

بازگشت نمایی و تلاش مجدد

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

به عنوان مثال، اولین تلاش مجدد ممکن است برای یک ثانیه، تلاش مجدد دوم برای دو ثانیه، سوم برای چهار ثانیه و غیره منتظر بماند.

توجه داشته باشید که از آنجایی که تلاش مجدد فوراً انجام نمی شود، احتمال تکرارهای آبشاری در مقایسه با زمانی که فوراً انجام می شد کاهش می یابد.

در اینجا کدی وجود دارد که عقب نشینی نمایی را در عمل نشان می دهد:

 def exponential_backoff_retry(url, max_retries=5, initial_delay=1, backoff_factor=2): retry_count = 0 while retry_count < max_retries: try: response = requests.get(url) # Check if the response was successful (status code 2xx) if response.status_code // 100 == 2: return response # If not successful, raise an exception to trigger a retry response.raise_for_status() except requests.exceptions.RequestException as e: print(f"Request failed: {e}") # Calculate the exponential backoff delay delay = initial_delay * (backoff_factor ** retry_count) print(f"Retrying in {delay} seconds...") time.sleep(delay) retry_count += 1 # If max retries reached, raise an exception raise RuntimeError(f"Failed to fetch {url} after {max_retries} retries")

کد بالا درخواست‌های HTTP GET را با استفاده از استراتژی عقب‌نشینی نمایی دوباره امتحان می‌کند.

در داخل حلقه while، سعی می کنیم درخواست را انجام دهیم و تحلیل کنیم که آیا پاسخ موفقیت آمیز است (درخواست های HTTP موفق دارای کد وضعیت 2xx هستند).

توجه داشته باشید که اگر درخواست با شکست مواجه شد، یک استثنا مطرح می کنیم و پس از محاسبه تاخیر نمایی، درخواست را دوباره امتحان می کنیم.

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

خلاصه

به طور خلاصه، ما به اهمیت ترافیک در سیستم های توزیع شده پرداختیم و بر تأثیر آن بر عملکرد و انعطاف پذیری سیستم تأکید کردیم.

ما به عوارض ناشی از افزایش ترافیک، از جمله تراکم شبکه، عدم تعادل بار، و خرابی های آبشاری که می تواند سیستم ها را در برابر فروپاشی آسیب پذیر کند، نگاه کردیم.

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

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

اینها تنها تعدادی از روشهای متعددی است که در صنعت برای مقابله با افزایش ترافیک استفاده می شود.

خبرکاو