Сделать SQS рабочий часовой пояс
Постановка задачи
У меня есть cron, который ставит рабочие места в очередь к работнику. Работник отправляет электронные письма пользователям. Рабочие места стоят в очереди для разных стран. Электронные письма следует отправлять только с 11:00 до 17:00 для каждой страны, то есть электронные письма пользователям из Австралии следует отправлять только с 11:00 до 17:00 по австралийскому времени, и то же самое относится ко всем другим странам.
Что я пробовал
Каждое из заданий знает о своем часовом поясе. При чтении задания, если оно не соответствует требованию времени, оно удаляется из очереди и добавляется с задержкой. Задержка рассчитывается на основе разницы от следующего приемлемого периода времени до текущего времени.
Но проблема с этим решением заключается в том, что задержка обычно составляет 17-18 часов. SQS Amazon имеет максимальную задержку 15 минут. Одним из обходных путей может быть задержка задания на 5 минут каждый раз, но это неэффективно, поскольку одно и то же задание будет выбрано несколько раз за эти 17-18 часов.
Другим ужасно неэффективным решением может быть наличие нескольких работников для каждой страны.
В настоящее время у меня есть несколько записей cron для одной и той же команды, чтобы ставить задания в очередь в то время, которое является приемлемым, то есть задания для Австралии ставятся в очередь в 11:00, так как линия cron для заданий в Австралии установлена в 11:00.
Я ищу эффективный механизм для решения этой проблемы. Все идеи приветствуются. Может кто-нибудь помочь мне здесь? Кроме того, каковы стандартные способы решения подобных проблем?
Решение
Вместо удаления сообщения из очереди, вы можете изменить его тайм-аут видимости.
Это действие оставляет сообщение в статусе «в полете», ожидая, пока вы его не удалите (чего вы на самом деле не будете делать) или пока не истечет время ожидания видимости. По истечении времени ожидания сообщение покидает статус «в полете» и сразу же становится снова пригодным для доставки … в этот момент ваш работник получит его снова и сможет решить, действовать ли на нем или сбросить время ожидания видимости еще раз.
Некоторые ограничения и соображения здесь:
-
Тайм-аут видимости имеет максимальный период 12 часов — не является серьезным ограничением, поскольку в худшем случае вам придется обработать его еще раз, прежде чем он будет иметь право на доставку.
-
Если вы используете очередь недоставленных сообщений, то счетчик для доставок должен быть достаточно высоким, чтобы эти операции, чтобы изменить видимость, не отправляли сообщение в очередь недоставленных сообщений преждевременно, поскольку это увеличит приблизительный счетчик приема для каждого сообщения на 1 каждое время его видимости истекает. Также небольшая проблема.
-
Основное соображение: очереди имеют ограничение в 120000 сообщений в полете одновременно. Поскольку это действие оставляет сообщение в состоянии «в полете», это решение выходит из строя, если вы ожидаете оставить столько сообщений, ожидающих прибытия окна их обработки. После того, как вы получите столько сообщений в полете, ваши длинные опросы не будут выполняться, пока некоторые сообщения не станут снова видимыми, потому что получение большего количества сообщений увеличит ваш счетчик в полете выше максимально допустимого значения в 120 000. Если ваш объем намного ниже этого, решение должно быть в порядке.
Обратите внимание, что я не предлагаю изменять время ожидания видимости для очереди, а скорее отправлять запрос в SQS, чтобы изменить время ожидания видимости для каждого сообщения, на которое вы хотите отложить обработку.
Другие решения
Других решений пока нет …
detector