AWS Lambda - кэширование MySQL
Моя репутация не позволит мне прокомментировать ответ, но я просто хотел указать, что самый высокий рейтинг здесь имеет ошибку:
RewriteEngine on
RewriteRule ^(.*)$ http://www.newdomain.com$1 [R=301,L]
должен иметь косую черту перед $ 1 , поэтому
RewriteEngine on
RewriteRule ^(.*)$ http://www.newdomain.com/$1 [R=301,L]
1 ответ
Прежде всего, нужно понять, как require работает в NodeJS. Я рекомендую вам пройти эту статью , если вам интересно узнать о ней больше.
Теперь, когда вам понадобится ваше соединение, оно у вас будет навсегда, и оно больше не потребуется. Это соответствует тому, что вы ищете, поскольку вы не хотите перегружать свою базу данных, каждый раз создавая новое соединение.
Но есть проблема ...
Лямбда-холодный запуск
Каждый раз, когда вы впервые вызываете лямбда-функцию, она раскручивает контейнер с вашей функцией внутри и поддерживает его в течение примерно 5 минут. Весьма вероятно (хотя и не гарантировано), что вы попадете в один и тот же контейнер каждый раз, пока вы делаете 1 запрос за раз. Но что произойдет, если у вас есть 2 запроса одновременно? Затем другой контейнер будет вращаться параллельно предыдущему, уже прогретому контейнеру. Вы только что создали другое соединение в вашей базе данных, и теперь у вас есть 2 контейнера. Теперь угадайте, что произойдет, если у вас есть 3 одновременных запроса? Да! Еще один контейнер, равный еще одному соединению с БД.
До тех пор, пока к вашим функциям Lambda поступают новые запросы, по умолчанию они будут масштабироваться для удовлетворения спроса (вы можете настроить его в консоли, чтобы ограничить выполнение столько одновременных исполнений, сколько вы хотите - с учетом ограничений вашей учетной записи. )
Вы не можете безопасно убедиться, что у вас есть фиксированное количество подключений к вашей базе данных, просто требуя ваш код при вызове функции. Хорошо, что это не твоя вина. Именно так ведут себя лямбда-функции.
... еще один подход -
для кэширования данных, которые вы хотите, в реальной системе кэширования, например, ElasticCache . Затем вы можете запустить одну лямбда-функцию с помощью CloudWatch Event , которое выполняется с определенной частотой времени. Затем эта функция будет запрашивать вашу БД и сохранять результаты в вашем внешнем кеше. Таким образом, вы убедитесь, что ваше соединение с БД открывается только одной лямбда-сетью за раз, поскольку она будет учитывать событие CloudWatch, которое, как оказывается, запускается только один раз для каждого триггера.
РЕДАКТИРОВАТЬ : после того, как ОП отправил ссылку в разделах комментариев, я решил добавить еще немного информации, чтобы уточнить, что упомянутая статья хочет сказать
" Все просто. Вы можете хранить переменные вне области действия нашей функции-обработчика. Это означает, что вы можете создать свой пул соединений с БД вне функции-обработчика, который затем может использоваться совместно с каждым последующим вызовом этой функции. пул может произойти. Опять же, вы можете проверить мой GitHub для примеров. "
И это именно то, что вы делаете. И это работает! Но проблема в том, что если у вас N подключений (лямбда-запросов) одновременно. Если вы не установите никаких ограничений, по умолчанию до 1000 лямбда-функций могут быть запущены одновременно. Теперь, если вы затем сделаете еще 1000 запросов одновременно в течение следующих 5 минут, очень вероятно, что вы не будете открывать какие-либо новые соединения, потому что они уже были открыты при предыдущих вызовах, и контейнеры все еще живы.