У нас есть одностраничное приложение с включенным рендерингом на стороне сервера. Мы разместились на AWS ELB.
Ресурсы приложения (js, css files) имеет хэш в имени файла, чтобы контролировать кеширование на стороне клиента / прокси и быть уверенным, что с момента появления новой сборки каждый наш клиент получит новую версию.
Чтобы все было хорошо, мы решили кэшировать весь документ с заголовком, телом и нижним колонтитулом. Это своего рода предварительно обработанный (со всеми компонентами) результат, который хранится в кеше. Работает неплохо, но есть проблема.
Независимо от того, какую стратегию развертывания мы используем, мы постоянно сталкиваемся с этим. У нас есть два экземпляра, и, поскольку мы развертываем новую сборку в одном из экземпляров с помощью метода Rolling (который рекомендуется AWS), мы аннулируем Memcache, но проблема в том, что экземпляр, который еще не был обновлен (предыдущая сборка), работает (обрабатывает запросы). Это означает, что если старый экземпляр получит запрос быстрее, чем новый (что бывает иногда), то мы получим в кеше старую версию документа, которая относится к несуществующим активам (со старым хешем в имени файла) .
Я вижу пару решений: 1. начните использовать простое имя файла для ресурсов (избегайте хешей) 2. не используйте memcache пока все экземпляры не будут обновлены, оба они не соответствуют нашим требованиям.
Есть ли другие решения?
Вы можете использовать сине-зеленые развертывания с жесткой балансировкой нагрузки, но мне интересно, будет ли это достаточно надежным. Теоретически определенный процент вашего трафика будет идти на новый сервер, включая запросы на статические ресурсы.
Другой вариант - развернуть статические ресурсы на всех серверах, а затем выполнить последовательное развертывание кода. Я бы не стал использовать здесь методы очистки кеша, я бы использовал имена файлов для обозначения версий ресурсов. Это означает, что вы можете кэшировать статические активы в течение длительного времени, но при этом легко переходить на новые версии при развертывании.
Другим вариантом может быть обслуживание всего трафика с одной машины, обновление другой машины и последующее переключение / переключение.
Это действительно зависит от вашего приложения, вашей нагрузки и ваших предпочтений. Возможно, вам подойдет одна из приведенных выше идей или, по крайней мере, у вас будет несколько вариантов для рассмотрения.