У меня также было такое же требование, когда я оценивал различные службы Queue, такие как RabbitMQ и Apache Kafka, но все эти службы требуют от нас обслуживания наших собственных серверов и управления ими. Проблема заключается в том, что обслуживание наших собственных серверов обходится дорого, и нам нужно самим управлять им в условиях масштабируемости (если только мы не используем сервер, обеспечивающий масштабируемость).
Затем я переключился на AWS SQS , с AWS Lambda , который идеально подходил для моих требований. Основным преимуществом является то, что он полностью без сервера, и AWS будет обрабатывать его масштабируемость. Нам необходимо отслеживать ограничения в каждой из служб, которые будут затронуты только в том случае, если мы перейдем на очень большой уровень.
Теперь давайте посмотрим, как это решение будет соответствовать вашим требованиям.
- Создание зависимостей между заданиями (например, запускать задание B только после завершения задания A)
Когда SQS получает сообщение, вы можете вызвать лямбда-функцию (задание A) и разрешить ее запуск (задание B), чтобы обеспечить поддержание порядка. Аналогичный подход может быть использован без лямбда-выражений, где вы можете направлять сообщения в том порядке, в котором вы хотите, после завершения каждого задания. Преимущество использования AWS SQS и Lambda состоит в том, что SQS обеспечивает функциональность вызова лямбд (функция, введенная в июне 2018 года), когда нам не нужно каждый раз опрашивать очередь.
- Разрешить повторное выполнение задачи, если подписчик не смог ее выполнить (без
отправить его обратно в очередь от абонента)
Если подписчик терпит неудачу, вы можете отправить сообщение в очередь недоставленных сообщений (DLQ), которая является другой очередью SQS, в которой хранятся сообщения, которые были отклонены получателем. (См. эту ссылку ). При этом вы можете использовать аналогичный подход, как упомянуто в 1., где вы можете позволить сообщениям в DLQ обрабатывать отдельно.
- Постоянство (в случае перезапуска сервера и т. Д.)
SQS сохраняет ваши сообщения в течение определенного периода времени. Вы можете указать период, в который вы хотите сохранить сообщение в очереди. Если вам нужно жесткое постоянство, срок действия которого не истекает через определенное время, рассмотрите возможность его хранения в базе данных или другом механизме хранения, например S3.
- Масштабирование (чтобы можно было добавить больше узлов в случае загрузки сервера)
По умолчанию AWS обеспечивает высокую масштабируемость, когда для каждого сервиса установлены определенные ограничения. Помните об ограничениях, когда они будут превышать только большие масштабы. (это всегда можно увеличить, обратившись в службу поддержки AWS)
- Преимущество: управляемое решение в AWS
Как указано выше, этими сервисами AWS управляет сам AWS. Так что нечего об этом беспокоиться, пока вы остаетесь в рамках.
Все решения, которые вы упомянули в вопросе, хороши, но их полезность зависит от сценария использования. В соответствии с упомянутыми требованиями, AWS SQS идеально подойдет для этого сценария.