بازگشت به کتابخانهکتابخانه2.3Horizontal Scaling و Load Balancer
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 2.3فصل ۲Scalability و ظرفیت

Horizontal Scaling و Load Balancer

  • ~۱۱ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

فروشگاه یک صندوق دارد. صف طولانی می‌شود. دو راه داری: صندوق گنده‌تر با یک صندوق‌دار خیلی سریع، یا چند صندوق معمولی و یک نفر دم در که مشتری را به صندوق خالی بفرستد. دنیای وب مدرن روی دومی بنا شده. آن آدم دم در را Load Balancer می‌نامند.

راه اول Vertical Scaling است — همان Scale Up: ماشین را قوی‌تر کن. راه دوم Horizontal Scaling است — همان Scale Out: ماشین بیشتر اضافه کن. سقف اولی سخت‌افزار و قیمت نمایی است. دومی عملاً بی‌سقف است؛ به شرطی که سرورها Stateless باشند.

چند صندوق و یک راهنما دم در
راهنما دم در مشتری را به صندوق خالی می‌فرستد. اگر یک صندوق بخوابد، بقیه کار می‌کنند. Load Balancer همین شغل را دارد.

بالا بردن یک ماشین، یا افزودن ماشین

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

VerticalScale UpHorizontalScale Out
روشCPU و RAM بیشتر به همان ماشینافزودن ماشین‌های بیشتر
سادگیبدون تغییر کدنیازمند Stateless بودن و LB
سقفسخت‌افزار حد دارد و قیمت نمایی می‌شودعملاً بی‌سقف
Fault Toleranceتک‌نقطه شکست — SPOFخرابی یک Node قابل تحمل
DIAGRAMLoad Balancer جلوی سرورهای Stateless
Client
Load Balancer
Server 1
Server 2
Server 3
Shared State — Redis / DB

چطور بار را پخش می‌کند؟

Load Balancer فقط «پخش کن» نیست. باید بداند نوبتی بدهد، ببیند کدام صندوق خلوت‌تر است، یا مشتری آشنا را به همان صندوق قبلی بفرستد. هر الگوریتم یک شغل دارد.

Round Robin
نوبتی. ساده و پیش‌فرض. با وزن — Weighted — برای سرورهای نابرابر: صندوق قوی‌تر سهم بیشتر می‌گیرد.
Least Connections
به سروری که کمترین اتصال فعال را دارد. وقتی بعضی درخواست‌ها طولانی‌اند، منصفانه‌تر از نوبتی است.
IP / Consistent Hash
کاربر ثابت به سرور ثابت. برای Cache محلی روی خود سرور، یا اتصال ماندگار. بوی Sticky می‌دهد؛ فقط وقتی دلیل داری.

L4 در برابر L7

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

L4Transport
فقط IP و Port را می‌بیند. بسیار سریع، تصمیم‌های ساده. مثل نگهبانی که فقط پلاک را چک می‌کند و راه می‌دهد.
L7Application
محتوای HTTP را می‌فهمد: مسیر، هدر، کوکی. می‌تواند /api را به یک سرویس بفرستد و TLS را همان‌جا تمام کند.
  • Health Check: سرور بیمار از چرخه خارج می‌شود؛ وقتی دوباره سالم شد، خودش برمی‌گردد.
  • خود LB نباید SPOF شود: حداقل دوتا — Active-Passive — یا DNS بین چند LB.
  • Sticky Session فقط وقتی State محلی داری — که خودش بوی طراحی بد می‌دهد. State را بیرون بکش.

به زبان ساده

یک صندوق گنده‌تر سقف دارد؛ چند صندوق معمولی پشت یک راهنما عملاً بی‌سقف است — به شرط Stateless بودن.

مثال واقعی

راهنما دم در مشتری را به صندوق خالی می‌فرستد. اگر یک صندوق بخوابد، فروشگاه نمی‌خوابد. آن راهنما Load Balancer است.

دانش‌سنجی

آزمون درس

۴ Q
01
سقف اصلی Vertical Scaling چیست؟
02
Routing بر اساس مسیر URL — مثلاً /api و /static — کار کدام است؟
03
برای درخواست‌هایی با طول بسیار متفاوت کدام الگوریتم منصفانه‌تر است؟
04
خود LB چطور SPOF نمی‌شود؟