Кэш метаданных доктрины во время атомарного развертывания

Question

Как вы обрабатываете кэш метаданных Doctrine во время развертывания приложения?

Мы используем стратегию атомарного развертывания для наших приложений symfony .До сих пор мы использовали метод кэширования file по умолчанию, который работает очень хорошо.Однако мы хотели бы переключиться на кэш в памяти, такой как Redis / Memcached, из соображений производительности.

Должны ли мы использовать какой-либо префикс идентификатора кэша для каждого выпуска?Например, когда выпускается новая версия программного обеспечения, сценарий развертывания прогревает приложение и заполняет кэш новыми метаданными схемы.В случае неудачного развертывания мы выполняем откат, и кэш метаданных будет по-прежнему действителен.

Какой наилучший метод для этого?Я бы хотел избежать скачков ЦП, когда поступают первые запросы и пока нет кэша метаданных.

Answer 1

Должны ли мы использовать какой-то префикс идентификатора кэша для каждого выпуска?

Да, такой подход я использовал несколько раз.Когда код находится на сервере, производители устанавливаются непосредственно перед переключением, нагревают кэш с уникальным префиксом.При откате будет использоваться кэш, который использовался до развертывания.

Установка префикса может быть сложной и зависит от вашей среды.Ваше приложение может читать из некоторого файла версии, который не содержит ничего, кроме уникального идентификатора версии.Ваше развертывание может создать это.Одним из вариантов является использование git-хеша текущего HEAD (или тега, если вы помечаете релизы).Старайтесь не полагаться на то, что разработчик вручную повысит версию.

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

• Записи кэша должны иметь срок жизни (например, с Redis, убедитесь, что истекает срок действия записей)
• Когда старый выпуск удаляется с сервера,его кэш также должен быть очищен.

Answer 2

Вот как мы это делаем:

1) Развертываем приложение на целевом сервере (используем хостинг AWS. Поэтому мы раскручиваем новый экземпляр, разворачиваем приложениекогда мы закончим, мы изменим основной сервер на новый, предварительно подготовленный)

2) Очистим кеши в следующем порядке:

php bin/console doctrine:cache:clear-metadata --env=prod
php bin/console doctrine:cache:clear-query --env=prod
php bin/console cache:clear --env=prod

3) Привести предварительно подготовленный экземплярк производству (в качестве LB-upstream)

---

Если что-то нужно откатить, мы подготавливаем откат на новом экземпляре (недоступном для публичных представлений) и снова очищаем кэши.Если все прошло хорошо, мы перенесем этот новый сервер в верхние потоки loadbalancer.

Мы работаем только с ключами кеша для категоризации, а также с пулами кеша, которые мы используем для группировки вещей.Мы получили Redis для Dev, один для подготовки к производству, так что в случае, если мы можем «FLUSHALL» в каждом Redis-Cli, и это не влияет на другие среды.

Надеюсь, это поможет!