Запланируйте задачу для выполнения в какой-то момент в будущем (архитектура)

Question

Итак, у нас запущено приложение фляги Python, использующее Celery и AWS SQS для удовлетворения наших асинхронных задач.

Одна сложная проблема, с которой мы столкнулись в последнее время, - это создание задачи, выполняемой за x дней,или через 3 часа, например.У нас было несколько потребностей для чего-то подобного.

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

Мы рассмотрели использование параметра eta в сельдерее (http://docs.celeryproject.org/en/latest/userguide/calling.html), который позволяет запланировать запуск задачи вx количество времени. Однако, кажется плохой практикой иметь большие etas, а также AWS SQS имеет тайм-аут видимости около двух часов, и поэтому все, что больше, чем это время, может вызвать конфликт.

Я чешумоя голова прямо сейчас. С одной стороны это работало, и довольно прилично в том, что вещи были отделены с помощью SNS, SQS и т. д. для обеспечения устойчивости к масштабированию. Однако, просто не хочется писать запрос к базе данных каждую секунду длясобытия для обработки. Конечно, есть более простой способ или услуга, предоставляемая Google / AWS, для планирования какого-либо события (pub / sub) на какое-то время в будущем (x часов, минут и т. д.)

Любые идеи

Answer 1

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

Answer 2

Посмотрели ли вы сервис Amazon Simple Notification?Звучит так, как будто это будет отвечать вашим потребностям ... https://aws.amazon.com/sns/

С этой страницы:

Amazon SNS - это полностью управляемая служба обмена сообщениями в пабах и подчиненных, которая делает еелегко развязывать и масштабировать микросервисы, распределенные системы и серверные приложения.С помощью SNS вы можете использовать разделы для отделения издателей сообщений от подписчиков, разветвления сообщений сразу нескольким получателям и исключения опроса в ваших приложениях.SNS поддерживает различные типы подписок, что позволяет отправлять сообщения непосредственно в очереди Amazon Simple Queue Service (SQS), функции AWS Lambda и конечные точки HTTP.Сервисы AWS, такие как Amazon EC2, Amazon S3 и Amazon CloudWatch, могут публиковать сообщения в ваших темах SNS для запуска управляемых событиями вычислений и рабочих процессов.SNS работает с SQS, предоставляя мощное решение для обмена сообщениями для создания облачных приложений, отказоустойчивых и легко масштабируемых.

Answer 3

Решение Amazon для планирования - это использование CloudWatch для запуска событий.Этими событиями могут быть помещение сообщения в конечную точку SQS / SNS, запуск задачи ECS, запуск лямбды и т. Д. Многие используют хитрость выполнения лямбды, которая затем делает что-то еще, чтобы вызвать что-то в вашей системе.Например, вы можете вызвать лямбду, которая помещает задание на Redis, чтобы рабочий из сельдерея мог его забрать.

При создании правила Cloudwatch вы можете указать либо «Скорость» (т. Е. Каждые 5 минут), либо произвольное время в синтаксисе CRON.

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

Answer 4

Вы можете запустить задание с apply_async, а затем использовать обратный отсчет, например:

xxx.apply_async (..., countdown = TTT)

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