Кэш шлюза AWS API — несколько обращений к сервису с массой вызовов

Я работаю над мобильным приложением, которое будет транслировать push-сообщение на сотни тысяч устройств одновременно. Когда каждый пользователь открывает свое приложение из push-сообщения, приложение обращается к нашему API за данными. Ресурс API будет одинаковым для каждого пользователя этого пуша.

Теперь предположим, что все 500 000 пользователей открывают свои приложения одновременно. Шлюз API получит 500 000 одинаковых вызовов.

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

Что я хочу сделать

Я хочу, чтобы API Gateway видел, что данные не находятся в кеше, пропускал первый вызов к моей серверной службе, в то время как другие запросы удерживались в очереди, заполнял кеш из первого вызова, а затем отвечал на другие 499 999 запросов, используя кэшированные данные.

Что происходит (кажется)

Шлюз API, видя, что кэшированное значение отсутствует, отправляет каждый из 500 000 запросов в серверную службу! Поэтому я буду пересчитывать значение с помощью какого-то сложного запроса к БД больше раз, чем позволяют ресурсы. Это происходит потому, что последний вызов поступает в шлюз API до того, как первый вызов заполнит кэш.

Есть ли способ получить такое поведение?

Я знаю, основываясь на моем примере, что, возможно, я мог бы заполнить кеш, вызвав вызов API непосредственно перед широковещательной рассылкой задания массовой рассылки, но фактический вариант использования немного сложнее, чем мой упрощенный пример. Но будьте уверены, решение этого упрощенного варианта использования решит то, что я пытаюсь сделать.


person Eric Olson    schedule 04.06.2016    source источник


Ответы (1)


Если вы ожидаете такой резкий параллелизм, самостоятельная загрузка кеша, безусловно, лучший вариант. Вы также рассматривали возможность добавления дросселирования в этап/метод, чтобы защитить серверную часть от большого всплеска трафика? Клиентам можно было дать указание повторить попытку дросселирования, и в конечном итоге они получили бы ответ.

Я передам ваш отзыв и предложенное решение команде и внесу его в список невыполненных работ.

person jackko    schedule 06.06.2016