انجین‌ایکس یک Web Server/Load Balancer/Reverse Proxy هست که از مدل event-driven به‌جای thread برای درخواست‌های ورودی استفاده می‌کنه.
سرعت رشد خوب NGINX این اجازه رو بهش داده که برای خیلی‌ها در واقع تبدیل بشه به یک وب‌سرور استاندارد.
مقیاس‌پذیری NGINX در شروع کار ممکنه سخت به نظر برسه چون خود NGINX مکانیزمی کلاستر کردن نداره. توی مقیاس‌پذیری معمولا اولین چیزی که به ذهنمون می‌رسه مقیاس‌پذیری عمودی هست اما در این مدل ما محدودیت‌های زیادی از جمله سخت‌افزار داریم. درکل مقیاس‌پذیری عمودی در بسیاری موارد راه حل بی‌سلیقه‌ای هست.
بزرگترین مشکل ما در مقیاس‌پذیری NGINX پیدا کردن cache هست! فرض کنید ما ده‌ها سرور لبه داریم و هر درخواست به‌صورت رندوم به یکی از این سرورها ارسال می‌شود. سرورهای NGINX که در بی خبری از یکدیگر به سر می‌برند سعی می‌کنند آن درخواست را کش کنند که باعث کاهش کارکرد کش می‌شود (مشکل فضای ذخیره‌سازی cache پیش‌کش).
یک راه حل که ممکن است به ذهن خطور کند به اشتراک‌گذاری فضای ذخیره‌سازی cache بین تمامی سرورها می‌باشد. اما به‌دلیل این که hash های درخواست‌ها در مموری ذخیره می‌شوند، سرورهای NGINX از فایل‌هایی که توسط دیگر سرورها ذخیره شده‌اند خبری ندارند و ... (درکل NGINX رابطه خوبی با فضاهای مشترک مخصوصا برای cache ندارد. مشکلاتی اعم از latency نیز وجود دارد).
امکان استفاده از Consistent Hashing برای فرستادن یک درخواست به یک سرور ثابت نیز در این مرحله برای ما وجود ندارد چون سرورهای NGINX در این ستاپ همگی سرور لبه هستند.
از سوی دیگر ما می‌توانیم این مشکل را با یک مدل کلاستر دو مرحله‌ای حل کنیم. این مدل یکی از مدل‌های پیشنهادی خود NGINX هست. برای فهمیدن این مدل تصویر زیر رو ببینید:
در این مدل ما روی هر سرور دو NGINX داریم؛ یکی به عنوان لودبالانسر و دیگری به عنوان کش سرور. هنگامی که یک درخواست HTTP به یکی از لودبالانسرها برسه (فرقی نداره کدوم) NGINX از روی یک key تعریف شده ( معمولا متشکل از URI و ... ) و با استفاده از Consistent Hashing و ایجاد هش یک کش سرور همیشه ثابت رو انتخاب می‌کنه. در دفعات بعد نیز اگر درخواست مشابهی در هر یک لودبالانسرها دریافت شد، درخواست به همان کش سرور ارسال می‌شود. حالا که کش سرور این درخواست را دریافت نموده مموری خود را چک کرده و اگر فایل کش وجود داشت آن را از روی فضای خود برگشت می‌دهد و اگر وجود نداشت درخواست را به سرور origin یا همان backend پراکسی می‌کند.
برای دوستان عزیزی که کد و کانفیگ فایل رو بهتر از متن توضیحات متوجه می‌شن، من یک کانفیگ مثال متشکل از ۳ سرور آماده کرده‌ام.
کانفیگ بالا رو می‌تونید متناسب با نیازتون تغییر بدید و روی تمامی سرورها اجرا کنید.
برای خوندن جزئیات بیشتر در این رابطه می‌تونید به Shared Caches with NGINX Plus Cache Clusters, Part 1 و Shared Caches with NGINX Plus Cache Clusters, Part 2 مراجعه کنید.
