Как устранить проблемы, вызванные кластеризацией или балансировкой нагрузки? - PullRequest
0 голосов
/ 20 ноября 2010

Привет, у меня есть приложение, которое развернуто на двух серверах приложений weblogic

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

Как мы докажем, действительно ли это так?

Ответы [ 2 ]

1 голос
/ 20 ноября 2010

Используете ли вы одно хранилище сеансов, к которому оба сервера приложений могут получить доступ по некоторому протоколу связи? Если нет, то это определенно так. Подумайте об этом: если ваши серверы weblogic хранят сеанс в памяти где-либо и когда пользователи передают свой идентификатор сеанса через куки, то другой сервер не имеет доступа к памяти на другом компьютере. Если вы не используете липкую балансировку нагрузки. Вы?

0 голосов
/ 25 апреля 2013

Здесь нужно рассмотреть две концепции - липкость сессии и репликация сессии.

Session Stickiness - это механизм, при котором сервер weblogic гарантирует, что если запрос от пользователя с сеансом A отправляется на сервер 1, то следующий запрос от пользователя с сеансом A отправляется только на сервер 1.

Это достигается путем настройки аппаратного балансировщика нагрузки (например, F5), который способен обеспечить стабильность сеанса. или настройку прокси-сервера weblogic, установленного в apache / iis / weblogic.

Когда запрос в первый раз достигает управляемого сервера WLS, он отвечает идентификатором сеанса и добавляет к нему идентификатор JVM сервера (это основной идентификатор). Если управляемый сервер является частью кластера, он также присоединяет идентификатор jvm вторичного сервера (вторичный сервер - это сервер, на котором реплицируется сеанс)

Прокси-сервер поддерживает таблицу всех идентификаторов JVM и соответствующих IP-адресов управляемого сервера, а также периодически проверяет, работают ли серверы или нет.

В следующий раз, когда другой запрос передает прокси с существующим идентификатором сеанса и первичным идентификатором jvm, прокси-сервер анализирует его и пытается отправить запрос на этот сервер, если он не может в течение некоторого времени попытаться отправить на вторичный сервер.

Репликация сеанса. Это включено по умолчанию при настройке кластера WLS с 2 или более управляемыми серверами. Каждый раз, когда какие-либо данные обновляются в сеансе, их данные также реплицируются на вторичном сервере.

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

Наконец, в примере развертывания приложения wls есть простой пример, который можно использовать для тестирования репликации сеанса и функций восстановления после отказа.

Итак, чтобы доказать, почему сессия теряется, 1) проверьте журнал сервера, чтобы увидеть, была ли сессия недействительной из-за тайм-аута, 2) если используется wlproxy, включите отладку, и в следующий раз проблема произойдет, проверьте в журнале прокси-сервера, был ли запрос отправлен на другой сервер, и если этот сервер не является вторичным сервером.

...