Когда следует использовать функцию очереди с задержкой в ​​Amazon SQS?

Один вариант использования, о котором я могу думать, - это использование в распределенных приложениях, которые имеют семантику возможной согласованности. Система, использующая сообщение, может иметь зависимость, такую ​​как доступность идентификатора взаимосвязи, и, следовательно, может потребоваться ожидание в течение определенного гарантированного периода времени, прежде чем увидеть данные взаимосвязи. В этом случае имеет смысл задержать сообщение на определенное время.

Как и вы, я был озадачен вариантом использования очередей с задержкой, пока не наткнулся на один из них в своей работе. Мое приложение должно иметь внутреннюю очередь, в которой каждый элемент ожидает не менее одной минуты между каждой проверкой на завершение.

Таким образом, вместо того, чтобы управлять «временем последней проверки» для каждого объекта, я просто помещаю идентификатор объекта в сообщение очереди SQS с временем задержки 60 секунд, и мой основной цикл становится простым длинным опросом очереди. .

Несколько из головы:

1. Электронные письма. Допустим, у вас есть служба, которая отправляет электронные письма с напоминаниями, запускаемыми из сообщений очереди. В этом случае вам придется отложить постановку сообщения в очередь.

2. Условия гонки. Задержки доставки можно использовать для преодоления условий гонки в распределенных системах. Например, служба может вставить строку в таблицу и отправить сообщение о ее доступности другим службам. Они пока не могут использовать новую запись, поэтому вам придется отложить публикацию сообщения SQS.

3. Обработка повторных попыток. Иногда, если сообщение не удается, вы хотите повторить попытку с экспоненциальным отставанием. Это требует повторной постановки сообщения в очередь с более длительными задержками.

Я создал набор API, чтобы упростить планирование сообщений в очереди. Вы можете вызвать наш API, чтобы запланировать сообщения очереди, отменить, изменить и проверить статус таких сообщений. Думайте об этом как о микросервисе планировщика.

www.schedulerapi.com

Если вы ищете решение, дайте мне знать. Я создавал эти планировщики раньше на работе для доставки электронных писем в больших масштабах, поэтому у меня есть опыт работы с подобными вариантами использования.

Один вариант использования может быть:

Подумайте о критичном по времени выражении, например, о запланированном ордере на сделку с ценными бумагами.

Если одна из ваших систем извлекает все заказы, запланированные на следующие 60 минут, и ставит их в очередь (которая будет получена другой подсистемой).

Если вы отправляете эти заказы напрямую, они сразу же будут видны для обработки в очереди и будут обрабатываться в зависимости от их порядка.

Но, скорее всего, они не будут выполняться в точное время (час:минута:секунды), в которое хотел Заказчик, и это повлияет на результат.

Итак, чтобы решить эту проблему, что будет делать первая подсистема, она добавит секунды задержки (разницу между текущим временем и временем выполнения), поэтому сообщение будет видно только после такой большой задержки или в точное время, когда пользователь этого хочет.