Где хранить объекты общего кэша в Cloud Run?

Относительно первого варианта (Вариант 1):

Функция heavyComputation() здесь будет вызываться только при холодном запуске, каждый раз создается новый экземпляр контейнера Cloud Run (когда максимально превышено количество запросов, которые можно отправить параллельно данному экземпляру контейнера, и поэтому создается новый экземпляр).

Чтобы решить второй вариант (Вариант 2):

На данный момент Cloud Run (полностью управляемый) не поддерживает бессерверный доступ к VPC, поэтому подключение к Cloud Memorystore невозможно. Отслеживайте следующий запрос функции, чтобы получать всю необходимую информацию и обновления от команды разработчиков Cloud Run, чтобы проверять, когда эта функция будет доступна.

Вы можете найти некоторые обходные пути в этом сообщении и в уже упомянутом запросе функции. В основном они состоят из:

1. Использование кластера Google Kubernetes Engine с Cloud Run.
2. Настройте экземпляр Redis на Compute Engine.

Мы начнем с вашей первоначальной предпосылки: «Я, очевидно, не хочу перезагружать его в память при каждом выполнении». Для меня это не всегда верное утверждение. Если я внедряю технологию кэширования, то, как программист, я трачу время на то, чтобы сделать ее правильно, и ввожу возможности для ошибок и обслуживания. Если бы я сэкономил 100 мс на выполнение, сколько тысяч и тысяч выполнений потребуется, чтобы окупиться при этих затратах по сравнению с экономией за счет увеличения времени выполнения? Обычно я заранее использую самый простой подход и готов отслеживать операции в будущем и вносить улучшения только в случае необходимости.

Тем не менее, давайте предположим, что вы определили, что будете делать миллион новых запросов на создание файлов в секунду и хотите оптимизировать. Ключ к пониманию того, как лучше всего использовать Cloud Run, заключается в том, что он запускает целый контейнер, который может обрабатывать одновременные запросы. Я полагаю, что значение по умолчанию равно 80. Это означает, что если бы было создано 80 одновременных файлов, был бы создан только один экземпляр контейнера и было бы обработано 80 параллельных событий. Если вы программируете на Java, это будет означать 80 одновременных потоков внутри одной и той же JVM. Каждый поток будет иметь параллельную адресацию к общей глобальной переменной. Только если поступил 81-й запрос и ни один из предыдущих 80 еще не был выполнен, будет создан новый контейнер Cloud Run.

Это говорит мне о том, что моим первым «улучшением» будет заполнение данных кеша в моей JVM при первом использовании и сохранение их для последующего повторного использования. Когда вы заполняете данные кэша? Это будет ваш выбор дизайна. Вы можете заполнить все это заранее при первом запуске контейнера... это было бы разумно, если бы вы знали, что данные будут использоваться для каждого запроса. В качестве альтернативы, если у вас есть несколько кэшируемых значений, рассмотрите возможность создания карты, которая содержит ваши пары имя/значение, и имеет метод доступа, который возвращает кэшированное значение (если есть) или извлекает из медленного хранилища, кэширует и возвращает значение (если оно изначально не присутствовало). ).