Кога да използвам функцията за забавяне на опашката на Amazon SQS?

Един случай на употреба, за който мога да се сетя, е използването в разпределени приложения, които имат евентуална семантика на последователност. Системата, използваща съобщението, може да има зависимост като идентификатор на корелация, за да бъде наличен и следователно може да се наложи да изчака определена гарантирана продължителност от време, преди да види данните за корелация. В този случай има смисъл съобщението да се забави за определен период от време.

Подобно на вас бях объркан по отношение на случая на използване на опашки със закъснение, докато не попаднах на такъв в собствената си работа. Приложението ми трябва да има вътрешна опашка с всеки елемент, който чака поне една минута между всяка проверка за завършване.

Така че, вместо да се налага да управлявам "последно време на проверка" за всеки обект, аз просто пъхам ID на обекта в съобщение на SQS опашката с време на забавяне от 60 секунди и главният ми цикъл след това се превръща в просто дълго проучване срещу опашката .

Няколко от главата ми:

1. Имейли – Да приемем, че имате услуга, която изпраща напомнящи имейли, задействани от съобщения в опашка. В този случай ще трябва да отложите поставянето на съобщението в опашка.

2. Състезателни условия - Закъсненията на доставката могат да се използват за преодоляване на състезателни условия в разпределени системи. Например услуга може да вмъкне ред в таблица и да изпрати съобщение за неговата наличност до други услуги. Те все още не могат да използват новия запис, така че трябва да отложите публикуването на SQS съобщението.

3. Обработка на повторни опити - Понякога, ако дадено съобщение е неуспешно, искате да опитате отново с експоненциални отстъпки. Това изисква повторно поставяне на съобщението в опашката с по-дълги забавяния.

Създадох набор от API, за да направя планирането на съобщения в опашката лесно. Можете да се обадите на нашите API, за да насрочите съобщения в опашка, да отмените, редактирате и проверите състоянието на такива съобщения. Мислете за това като за микроуслуга за планировчик.

www.schedulerapi.com

Ако търсите решение, уведомете ме. Създавал съм тези планировчици преди на работа за доставяне на имейли в голям мащаб, така че имам опит с подобни случаи на употреба.

Един случай на използване може да бъде:

Помислете за критичен във времето израз като планирана търговска поръчка за акции.

Ако една от вашите системи извлича всички поръчки, планирани за следващите 60 минути, и ги поставя в опашка (която ще бъде извлечена от друга подсистема).

Ако изпратите тези поръчки директно, те ще бъдат видими веднага за обработка в опашката и ще бъдат обработени в зависимост от тяхната поръчка.

Но най-вероятно те няма да се изпълнят в точното време (час:минута:секунди), в което клиентът е искал и това ще повлияе на резултата.

Така че, за да реши това, какво ще направи първата подсистема, тя ще добави секунди закъснение (разлика между текущото и времето за изпълнение), така че съобщението ще бъде видимо само след толкова много забавяне или в точното време, когато потребителят поиска.