производительность — отправка тысяч уведомлений на PHP (Symfony2) с помощью SQS
У меня есть приложение Symfony2, которое при некоторых обстоятельствах должно отправлять более 10.000 push-уведомлений и уведомлений по электронной почте.
Я разработал поток SQS с некоторыми работниками, опрашивающими очереди для отправки электронных писем и мобильных push-уведомлений.
Но теперь у меня есть проблема в том, что, когда в цикле запроса / ответа мне нужно отправить в SQS эту задачу / задания (возможно, не ту сумму), эта задача сама по себе отнимает много времени (обычно достигается время ожидания ответа).
Должен ли я выполнить эту задачу в фоновом режиме (мне нужно отправить быстрый ответ)? И как справиться с возможными ошибками в этом сценарии?
ПРИМЕЧАНИЕ: Amazon SQS может получать 10 сообщений за один запрос, и я уже использую этот метод. Может быть, мне следует создать простое сообщение SQS с большим количеством заданий на уведомления (макс. 256 КБ), чтобы отправлять меньше запросов HTTP в SQS?
Решение
В тот момент, когда у вас есть одно действие, которое запускает 10k действий, вам нужно попытаться найти способ сказать пользователю: «Хорошо, я понял. Я начну работать над ним и сообщу вам, когда это будет сделано».
Таким образом, чтобы перенести эту работу в фоновый режим, из действия вашего пользователя должно быть инициировано событие домена, которое будет помещено в очередь в SQS. Пользователь получает уведомление, а затем работник может забрать это сообщение из очереди и начать отправлять электронные письма и отправлять уведомления в другую очередь.
В конце концов, 10 тыс. Сообщений в пакетах по 10 штук — это всего лишь 1 тыс. Запросов к SQS, что в любом случае должно быть довольно быстрым.
Постарайтесь, чтобы ваши сообщения были маленькими. Не отправляйте весь контент письма в очередь сообщений, потому что тогда вы получите ненужные длинные задержки. Храните контент в доступном месте или просто запросите его снова при использовании сообщения вместо передачи большого контента вверх и вниз по сети.
Другие решения
И как справиться с возможными ошибками в этом сценарии?
Amazon предоставляет очереди мертвых писем за это. В асинхронных системах, которые я построил, я обычно создаю очередь и затем присоединяю к ней политику переадресации, которая гласит: «Если я вижу одно и то же сообщение в этой очереди 10 раз, отправьте его в очередь недоставленных сообщений, чтобы она не отскочила» вперед и назад между очередью и потребителем на всю вечность «. Очередь мертвых писем — просто очередная очередь.
Из очереди недоставленных сообщений вы можете решить, что делать с данными, которые не были обработаны. Поскольку в вашем случае это уведомления (электронные письма или push-уведомления), в вашей системе может быть другой компонент, который будет периодически повторно обрабатывать очередь недоставленных сообщений. Запланированные лямбды хороши для этого.
detector