از صفی استفاده کنید که به‌عنوان یک بافر بین یک تسک و سرویسی که آن را فراخوانی می‌کند، عمل می‌کند تا بارهای سنگین متناوب را که می‌توانند باعث ازکارافتادن سرویس یا time-out تسک شوند را هموار کند. این مورد می‌تواند جهت به‌حداقل‌رساندن تأثیر اوج تقاضا روی دردسترس‌بودن(availability) و پاسخگویی (responsiveness) هم برای تسک و هم برای سرویس کمک کند.
بسیاری از راه‌حل‌ها در فضا و معماری ابری شامل اجرای تسک‌‌هایی است که سرویسهایی را فراخوانی می‌کنند. در این محیط، اگر سرویسی تحت بارهای سنگین متناوبی قرار گیرد، می‌تواند باعث مشکلاتی در کارایی یا اطمینان سنجی (reliability) شود.
یک سرویس می‌تواند بخشی از همان راه‌حلی باشد که تسک‌‌هایش که از آن استفاده می‌کنند یا می‌تواند یک سرویس شخص ثالث(third-party) باشد که دسترسی به منابع پرکاربرد مانند حافظه کَش(cache) یا سرویس ذخیره‌سازی را فراهم می‌کند. اگر از همان سرویسی که توسط تعدادی از تسک‌‌هایی که به طور هم‌زمان اجرا می‌شوند استفاده شود، پیش‌بینی حجم درخواستهای سرویس در هر زمان ممکن است دشوار باشد.
یک سرویس ممکن است حالت اوج تقاضا را تجربه کند که باعث می‌شود بیش از حد بارگذاری شود و نتواند به درخواست‌ها به‌موقع پاسخ دهد. تعداد زیاد درخواست هم‌زمان روی سرویس درصورتی‌که نتواند پاسخ به حجم بالایی از این درخواست‌ها پاسخ‌دهی کند، می‌تواند منجر به شکست سرویس شود.
راه‌حل را اصلاح کنید و یک صف بین تسک و سرویس تعریف کنید. تسک و سرویس به صورت ناهم‌زمان اجرا می‌شوند. تسک پیامی حاوی داده‌های موردنیاز سرویس را به یک صف ارسال می‌کند. صف به‌عنوان یک بافر عمل می‌کند و پیام را تا زمانی که توسط سرویس بازیابی شود ذخیره می‌کند. این سرویس پیامها را از صف بازیابی می‌کند و آنها را پردازش می‌کند. درخواستهای تعدادی از تسک‌ها که می‌توانند با نرخ تغییرات بسیار تولید شوند، می‌توانند از طریق همان صف پیام به سرویس ارسال شوند. این شکل استفاده از یک صف برای ترازکردن بار روی یک سرویس را نشان می‌دهد.
صف، تسک‌ها را از سرویس جدا می‌کند و سرویس می‌تواند پیامها را بدون توجه به حجم درخواستهای تسک‌ها هم‌زمان با سرعت خودش مدیریت کند. علاوه بر این، اگر سرویس در زمانی که پیامی را به صف ارسال می‌کند، در دسترس نباشد، هیچ تاخیری برای انجام تسک وجود ندارد.
این الگو دارای مزایای زیر است:
* می‌تواند جهت به حداکثر رساندن دردسترس‌بودن (availability) سرویس کمک کند؛ زیرا تأخیرهای ایجاد شده در سرویس‌ها تأثیر فوری و مستقیمی بر برنامه نخواهد داشت در نتیجه می‌تواند به ارسال‌کردن پیامها در صف ادامه دهد حتی زمانی که سرویس در دسترس نیست یا زمانی که پیامها را پردازش نمی‌کند.
* می‌تواند به حداکثرکردن مقیاس‌پذیری کمک کند، زیرا هم تعداد صف‌ها و هم تعداد سرویس‌ها می‌توانند برای پاسخگویی به تقاضا متفاوت باشند.
* می‌تواند به کنترل هزینه‌ها کمک کند، زیرا تعداد نمونههای سرویس deploy شده فقط باید برای برآورده‌کردن بار متوسط (average load) به‌جای بار اوج (peak load) کافی باشد.
برخی از سرویس‌ها زمانی که تقاضا به آستانه‌ای می‌رسد که سیستم ممکن است از کار بیفتد، الگوی throttling را اجرا می‌کنند. throttling می‌تواند عملکرد موجود را کاهش دهد. برای اطمینان از عدم رسیدن به این آستانه، می‌توانید با کمک این سرویس‌ها load leveling را پیاده‌سازی کنید.
هنگام تصمیم‌گیری در مورد نحوه اجرای این الگو به نکات زیر توجه کنید: * در پیاده‌سازی منطق این برنامه مهم است که نرخ مدیریت پیامها توسط سرویس‌ها را کنترل کنیم تا از تسخیر منبع هدف جلوگیری شود. از انتقال افزایش تقاضا به مرحله بعدی سیستم خودداری کنید. سیستم را تحت بار آزمایش کنید تا مطمئن شوید که سطح کارایی موردنیاز را فراهم می‌کند و تعداد صف‌ها و تعداد نمونههای سرویسی که پیامها را مدیریت می‌کنند را برای رسیدن به این هدف تنظیم کنید.
* صف‌های پیام (Message queues) یک سازوکار ارتباطی یک‌طرفه هستند. اگر تسک‌ای انتظار پاسخ از یک سرویس را دارد، ممکن است لازم باشد مکانیزمی را پیاده‌سازی کرد که سرویس بتواند از آن برای ارسال پاسخ استفاده کند. برای اطلاعات بیشتر، به Asynchronous Messaging Primer مراجعه کنید.
* اگر autoscaling را برای سرویسهایی که در حال گوش‌دادن به درخواست‌ها در صف هستند را اعمال می‌کنید، حتماً مراقب باشید که این مورد می‌تواند منجر به افزایش تداخل و تضاد برای مصرف هر گونه منابعی شود که این سرویس‌ها به اشتراک می‌گذارند و اثربخشی استفاده از صف برای ترازکردن بار(load balance) را کاهش می‌دهد.
* بسته به load قرار گرفته روی سرویس می‌توانید در موقعیتی قرار بگیرید که در آن به طور مؤثر همیشه در پردازش درخواست‌ها عقب هستید به‌خصوص در زمانی که در آن سیستم همیشه درخواستهای بیشتری را نسبت به آنچه که شما پردازش می‌کنید در صف قرار می‌دهد. تنوع بار ترافیکی ورودی به برنامه شما باید در نظر گرفته شود.
* بسته به ماندگاری صف می‌تواند اطلاعات را از دست بدهد. اگر صف شما خراب شد یا اطلاعات را از دست داد (به دلیل محدودیت‌های سیستم)، این احتمال وجود دارد که در تحویل پیامها تضمینی نداشته باشید. رفتار صف و محدودیت‌های سیستم شما باید بر اساس نیازهای راه‌حل شما در نظر گرفته شود.
این الگو برای هر برنامه‌ای که از سرویسهایی استفاده می‌کند که در معرض بارگذاری بیش از حد هستند، مفید است. اگر برنامه انتظار پاسخی از سرویس با حداقل تأخیر داشته باشد، این الگو مفید نیست.
یک web app، داده‌ها را در یک data store خارجی می‌نویسد. اگر تعداد زیادی از نمونههای web app به طور هم‌زمان اجرا شوند، ممکن است data store نتواند به‌سرعت به درخواست‌ها پاسخ دهد که باعث می‌شود درخواست‌ها دچار time-out شده یا حذف یا درنهایت دچار شکست شوند. نمودار زیر نشان می‌دهد که یک data store تحت‌تأثیر تعداد زیادی درخواست هم‌زمان از نمونههای یک application است.
برای حل این مشکل، می‌توانید از یک صف برای ترازکردن بار بین نمونههای برنامه و ذخیره داده استفاده کنید. یک برنامه Azure Functions پیامها را از صف می‌خواند و درخواستهای خواندن/نوشتن را به data store انجام می‌دهد. منطق این اپلیکیشن در این function app می‌تواند سرعت ارسال درخواست‌ها را به data store کنترل کند تا از فروپاشی ذخیره‌گاه داده جلوگیری کند. (در غیر این صورت function app فقط همان مشکل را در backend ایجاد می‌کند).
راهنمایی زیر ممکن است هنگام اجرای این الگو نیز مرتبط باشد:
* Asynchronous Messaging Primer. صف‌های پیام(Message queues) ذاتاً ناهم‌زمان هستند. در نتیجه ممکن است نیاز به طراحی مجدد منطق برنامه در یک سری از تسک‌ها باشد به‌خصوص زمان که برقراری ارتباط مستقیم با یک سرویس به استفاده از Message queues تطبیق داده شده باشد. به طور مشابه، ممکن است لازم باشد یک سرویس برای پذیرش درخواستهای یک Message queues مجدداً بازسازی شود. از طرف دیگر، ممکن است بتوان یک سرویس پروکسی را همان‌طور که در مثال توضیح داد، پیاده‌سازی کرد.
* Choose between Azure messaging services. که اطلاعاتی در مورد انتخاب مکانیزم پیام‌رسانی و صف‌بندی در برنامه‌های Azure است
* Asynchronous message-based communication
* Web-Queue-Worker architecture style. وب و worker هر دو stateless هستند. وضعیت Session را می‌توان در یک کش توزیع شده (distributed cache) ذخیره کرد. هر تسک طولانی‌مدت توسط worker به صورت ناهم‌زمان انجام می‌شود. worker می‌تواند توسط پیام‌‌های موجود در صف فعال شود یا بر اساس برنامه‌ای برای پردازش دسته‌ای اجرا شود.
الگو‌های زیر نیز ممکن است هنگام اجرای این الگو مرتبط باشند:
* الگوی Competing Consumers pattern ممکن است بتوان چندین نمونه از یک سرویس را اجرا کرد که هر کدام به‌عنوان یک مصرف‌کننده پیام (consumer) از load-leveling queue عمل می‌کنند. شما می‌توانید از این روش برای تنظیم نرخ دریافت و ارسال پیامها به یک سرویس استفاده کنید.
* الگوی Throttling pattern. یک راه ساده برای پیاده‌سازی throttling با یک سرویس، استفاده از سطح‌بندی بار مبتنی بر صف(queue-based load leveling) و مسیریابی همه درخواست‌ها به یک سرویس از طریق یک صف پیام(message queue) است. این سرویس می‌تواند درخواست‌ها را با سرعتی پردازش کند که تضمین کند منابع موردنیاز سرویس تمام نشده‌اند و میزان درگیری که ممکن است رخ دهد را کاهش دهد.