دستیابی به تاخیر کم با pub/sub

در سیستم‌های پیام‌رسانی pub/sub، انتقال سریع پیام‌ها بین ناشران و کاربران نه تنها برای عملکرد کلی آن حیاتی است، بلکه برای قابلیت استفاده اولیه آن نیز اهمیت دارد. دستیابی به این در مقیاس، چالش‌های اضافی را به وجود می‌آورد که نیازمند طراحی معماری متفکرانه و استراتژی‌هایی برای مدیریت رفتارهای غیرمنتظره (مانند افزایش ترافیک) است.

برای درک بهتر بهترین شیوه‌هایی که می‌توانیم در معماری خود برای غلبه بر این چالش‌ها پیاده‌سازی کنیم، بیایید نحوه عملکرد الگوی میخانه/فرعی را دوباره بررسی کنیم.

pub/sub چیست؟

Pub/sub (یا انتشار/اشتراک) یک الگوی طراحی معماری است که در سیستم های توزیع شده برای ارتباط ناهمزمان بین اجزا یا خدمات مختلف استفاده می شود. اگرچه انتشار/اشتراک بر اساس الگوهای طراحی قبلی مانند صف پیام و کارگزاران رویداد است، اما انعطاف پذیرتر و مقیاس پذیرتر است. نکته کلیدی در این واقعیت این است که pub/sub امکان حرکت پیام ها را بین اجزای مختلف سیستم بدون اینکه اجزا از هویت یکدیگر آگاه باشند (آنها جدا شده اند) را امکان پذیر می کند.

برای بررسی عمیق تر در pub/sub، از جمله مثال ها و مقایسه با سایر الگوهای پیام رسانی، به راهنمای ما مراجعه کنید: pub/sub چیست؟.

چرا تأخیر برای سیستم‌های هم‌زمان میخانه/فرعی حیاتی است

تأخیر زمانی است که طول می کشد تا داده ها از باطن (مانند یک مرکز داده) به دستگاه کاربر نهایی منتقل شوند. به طور کلی دستیابی به سطوح تأخیر کمتر از 100 میلی‌ثانیه دشوار است، اما برای سیستم‌های میخانه/زیر، ضروری است که این سرعت‌ها نه تنها ثابت باقی بمانند، بلکه غیرقابل تشخیص باشند تا کاربران درگیر باقی بمانند و به طور کامل برنامه را ترک نکنند. برنامه‌هایی که به‌عنوان مثال، بر روی به‌روزرسانی‌های مهم پخش، چت بی‌درنگ، و سرویس‌های پخش زنده تمرکز می‌کنند، باید بتوانند تجربیات یکپارچه را با تأخیر بسیار کم ارائه دهند تا پایگاه کاربران خود را حفظ کنند.

این امر به ویژه در مقیاس برای مخاطبان جهانی اهمیت پیدا می‌کند: اگر یک سیستم میخانه/زیر سیستم نتواند این سرعت‌ها را با افزایش مقیاس و رسیدن به یک پایگاه کاربر جهانی حفظ کند، تاخیر پیام می‌تواند آن را غیرقابل استفاده کند، حتی اگر زیرساخت شما ظرفیت خام را داشته باشد. سرویس دهی به یک منطقه به طور قابل توجهی ساده تر از دستیابی به تأخیر کم ثابت در بین مخاطبان جهانی توزیع شده است، که در آن عواملی مانند تکرار داده های بین منطقه ای و تنوع شبکه نقش دارند. تأخیر متوسط ​​جهانی اگر در مقیاس کار می کنید، معیار خوبی برای میانگین تأخیر جهانی است، و این معیاری است که ما برای اندازه گیری سرعت خود در Ably استفاده می کنیم.

برخی از تصمیمات معماری که می توانید برای رسیدن به تاخیر کم بگیرید عبارتند از:

• پوشش جهانی دیتاسنتر: نزدیکی فیزیکی مراکز داده یا نقاط لبه حضور (PoP) به کاربران نهایی به طور قابل توجهی بر زمان رفت و برگشت پیام ها تأثیر می گذارد. اگر دیتاسنترها و پاپ ها را در سطح جهانی توزیع کنید، می توانید تاخیر را برای کاربران خود کاهش دهید.

• کارایی پروتکل: انتخاب پروتکل بر نحوه انتقال کارآمد پیام ها تأثیر می گذارد. به عنوان مثال، WebSocket برای ارتباطات بلادرنگ در مقایسه با نظرسنجی طولانی HTTP بسیار کارآمد است. (WebSocket ها پروتکل خوبی برای دستیابی به تأخیر کم در سیستم‌های pub/sub هستند، زیرا آنها یک ارتباط باز بین مشتری و سرور بدون نیاز به پاسخ‌های مکرر HTTP حفظ می‌کنند. برای بررسی عمیق‌تر نحوه مقایسه WebSockets با سایر پروتکل‌ها در pub/sub. سیستم‌ها، راهنمای ما Pub/Sub در مقابل WebSockets را بررسی کنید.)

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

چالش‌های دستیابی به تاخیر کم

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

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

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

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

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

بهترین روش ها برای دستیابی به تاخیر کم

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

از معماری توزیع شده در سطح جهانی استفاده کنید

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

بهینه سازی مسیریابی پیام

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

یک بار متعادل کننده داشته باشید

تعادل بار پویا ترافیک را به طور یکنواخت در بین سرورها توزیع می کند و از اضافه بار جلوگیری می کند. برای سیستم‌های pub/sub، متعادل‌کننده‌های بار باید هم تعداد اتصال و هم خروجی پیام را در نظر بگیرند.

از فشرده سازی دلتا پیام استفاده کنید

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

مقیاس خودکار برای کاهش مصرف منابع

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

افزونگی و شکست داشته باشد

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

چگونه توانا می تواند کمک کند

برای بسیاری از افراد، ساختن یک سیستم با تمام این اجزاء از پایه غیرعملی است و یک سرمایه گذاری زمان و مهارت عظیم است. این سرمایه‌گذاری همچنین به دلیل هزینه‌های تعمیر و نگهداری و چالش‌های دیگر – مانند مقیاس‌پذیری و یکپارچگی داده‌ها – که حفظ تأخیر به اندازه کافی پایین را دشوارتر می‌کند، گران‌تر از حد انتظار اولیه است.

در Ably، تیم ما با میزان کاری که برای ساختن یک سیستم میخانه/زیر سیستم با تأخیر کم انجام می‌شود – و همه موارد لبه در مورد عملکرد بهینه بسیار آشنا هستند. ما وظیفه خود را بر این گذاشته ایم که مطمئن ترین سرویس بیدرنگ را برای شما ارائه دهیم – و Ably Pub/Sub به موارد استفاده از میخانه/زیر اختصاص داده شده است.

انتخاب یک میخانه/سرویس فرعی مدیریت شده مانند Ably می تواند شما و تیمتان را از دردسر مدیریت چالش های معماری با تاخیر کم در مقیاس نجات دهد. عملکرد یکی از ستون های اصلی Ably است و در کاری که ما انجام می دهیم تعبیه شده است. در اینجا به این صورت است:

• عملکرد قابل پیش بینی: یک شبکه لبه جهانی با تأخیر کم و بازده بالا، با تأخیر متوسط ​​کمتر از 50 میلی‌ثانیه.

• سفارش و تحویل تضمینی: پیام ها به ترتیب و دقیقا یک بار و با اتصال مجدد خودکار تحویل داده می شوند.

• زیرساخت های مقاوم در برابر خطا: افزونگی در سطوح منطقه‌ای و جهانی با 99.999% SLA uptime. 99.999999% (8x9s) در دسترس بودن و بقای پیام، حتی با خرابی مرکز داده.

• مقیاس پذیری و در دسترس بودن بالا: ساخته شده و آزمایش شده برای مقابله با میلیون ها اتصال همزمان در مقیاس.

• زمان و هزینه های بهینه ساخت: استقرارها معمولاً 21 برابر هزینه کمتر و بیش از 1 میلیون دلار صرفه جویی در سال اول دارند.

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