WildFly 10 HA deploy: не проигрывающие сессии

Question

Я читал сообщения и документацию весь день об этой теме и до сих пор не могу найти что-то легкое для понимания и доверия.

У меня в настоящее время мой webapp развернут на WildFly 10, как простой файл войны.

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

Мне нужно решение для развертывания новой войны без перезапуска сервера приложений. Сначала я прочитал документы о кластеризации (настройка домена по автономной конфигурации), но я не уверен, что этого достаточно для меня ...

Представьте себе одного и того же клиента с несколькими товарами в корзине покупок (http session) , доступ к первому узлу кластера. Тогда я положил его, потому что я развертываю. ОК, клиент будет перенаправлен ко второму узлу кластера, но ... будут ли доступны данные сеанса? Будет ли он «потерять» товары в корзине?

Я читал о липких сеансах, но ничего не сообщил о настройке их в WildFly. Я на Amazon AWS, поэтому я могу использовать ELB (балансировщик нагрузки). Можете ли вы помочь мне понять, что мне нужно, чтобы учиться и использовать?

Answer 1

Каждый экземпляр WildFly будет иметь свой собственный идентификатор сеанса, который хранится в файле cookie. Этот идентификатор восстановит сеанс только на том узле, из которого он пришел.

Личные сессии означают, что ELB всегда перенаправляет пользователя на тот же узел в вашем кластере, чтобы не решить вашу проблему.

Некоторые вещи, чтобы думать:

кластеризация

кластеризация может помочь (не нужно быть режим домена). При включенной функции HA сеанс будет автоматически передаваться между узлами, так что cookie в браузере клиентов сможет восстановить сеанс на любом узле. У этого, конечно, есть проблема, когда, если вы обновляете один из военных файлов, сначала у вас может быть объект, который больше не может быть де-сериализован, потому что он изменился.

Кластеризация WF на AWS немного сложна, потому что вы не можете использовать широковещательную передачу UDP, чтобы обнаружить друг друга. Мы используем соединение с базой данных для отслеживания узлов и кластеризации.

Ролл свой собственный

Один из вариантов вы можете сделать, это катить собственное решение сохранить только минимальное количество информации о клиенте по мере необходимости. Что-то вроде:

1. создать запись в базе данных с помощью GUID.
2. установить GUID в кук
3. Сохранить элементы в своей корзине в базе данных на основе GUID
4. есть фильтр, который проверяет куки GUID и может восстановить их телега каждый раз, когда они попали на сайте.

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

Использование Tomcat параллельное развертывание

ли ваше приложение требует полного сервера приложений? Если это просто основанный на сервлете, вы можете попробовать использовать Tomcat и его параллельное развертывание. Это позволяет вам развернуть свой новый .war-файл поверх старого. Затем он будет обслуживать старые сеансы старой войны, но новые сессии перейдут в новый военный файл.

Параллельное развертывание очень круто, если ваше приложение достаточно просто, чтобы иметь возможность использовать tomcat.