Я бы выбрал здесь немного другой подход, но похожий.
- Запрос базы данных для пользователей
- L oop через пользователей
- Отправка одного сообщения в SQS для отправки пакета записей и использование
SendMessageBatch операция SQS для их отправки. Итак, партии партий. Каждая партия сообщений будет иметь несколько «пользователей» для отправки, а не только один. Это должно повысить вашу производительность, потому что пакет будет требовать меньше лямбда-вызовов. - Lambda обрабатывает сообщения SQS (возможно, более одного), и каждое сообщение SQS приводит к отправке большого количества уведомлений pu sh. Я полагаю, что в случае с Firebase есть способ отправки пакетов, что еще лучше. Даже без этого вы можете отправлять несколько сообщений одновременно, используя
Promise.all type logi c.
С этой структурой вы можете отправлять очень большое количество сообщений очень быстро, и, вероятно, намного дешевле , Представьте, что вам нужно отправить 1М пользователям. Если вы отправляете пакеты по 100, партиями по 25 в SQS, то у вас есть 2500 сообщений на вызов в SQS. Это будет означать 400 вызовов в SQS, что намного лучше, чем даже 40K, которые вы должны были бы сделать, если бы отправляли отдельные сообщения партиями по 25.
На принимающей стороне, даже если вы снизили интеграцию SQS до 1 сообщение на один вызов, вы получите 10000 лямбда-вызовов. Если вы примете хотя бы 1 с на вызов и 1000 одновременных вызовов, это займет 10 секунд (вероятно, меньше). Если вы отправляете одно сообщение на пользователя, вам нужно будет сделать 1M лямбда-вызовов. Если вы предполагаете, что каждый вызов занимает 100 мс, вы можете отправить 10 / секунду, поэтому при 1000 одновременных выполнениях это займет 100 секунд. На самом деле цифры, вероятно, даже лучше, чем у пакетной версии, особенно если вы не ограничиваете ее одним сообщением за раз.
Редактировать Основываясь на комментариях, вопрос казался чтобы быть немного больше о первой части процесса. Имея это в виду, я бы предложил следующие варианты:
- Если вам часто приходится обращаться к одним и тем же большим группам, большинство служб обмена сообщениями (Firebase и SNS наверняка) поддерживают какие-то топи c модель подписки. Учитывая, что это уведомления pu sh, вы можете подписать устройство на topi c в коде. В конечном итоге это приводит к тому, что сообщения отправляются из вашего кода в службу обмена сообщениями. Сервис обрабатывает все остальное. Вероятно, это предпочтительное решение для всего, что имеет массовых получателей, особенно если вы можете знать получателей заранее. Это даже работает для динамических тем c. Например, рассмотрим ситуацию, когда человек комментирует сообщение. Любой новый комментарий к этому посту должен посылать сообщение всем, кто прокомментировал этот пост. Вы можете создать топи c на лету при создании сообщения и добавлять получателей в топи c, когда они комментируют. Если пользователь желает прекратить получать сообщения, вы можете удалить его из списка c.
- . Если вы не знаете получателей заранее, вышеприведенное решение является решением solid. Однако, если вы беспокоитесь о времени ожидания лямбды на первых двух шагах, я бы немного изменил. Я бы воспользовался AWS пошаговыми функциями и разместил данные в лямбде. Lambda сообщит вам, через объект
context, указанный в вызове, сколько времени осталось. Вы можете периодически проверять это, чтобы определить, следует ли вам выйти из лямбды и передать в пошаговую функцию текущую информацию о поисковом вызове. Функция шага может передавать эту информацию о поисковом вызове обратно в лямбду, которая должна быть закодирована, чтобы принимать информацию о поисковом вызове как часть запроса, и продолжать с этой точки, если она предоставляется.