Веб-приложение баланса нагрузки

Ответ 1

Прежде всего, вы захотите настроить балансировщик нагрузки для сеансовых аффинированных/липких сеансов, чтобы он продолжал пересылать все запросы одному и тому же Tomcat (до тех пор, пока он работает) на основе JSESSIONID.

В документе кластеризации Tomcat говорится о двух важных требованиях к вашему приложению, чтобы успешно реплицировать сеансы:

• Все ваши атрибуты сеанса должны реализовывать java.io.Serializable
• Убедитесь, что ваш web.xml имеет элемент <distributable/> или установлен в вашем <Context distributable="true" />

Если вы начинаете помещать объекты в сеанс, которые не реализуют Serializable (или которые имеют свойства/поля, которые не реализуют Serializable), тогда у вас будут проблемы.

(На самом деле эти точки применяются независимо от того, какой контейнер сервлетов вы используете, я считаю.)

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

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

Наличие среды, в которой вы держите данные в сеансе, но у вас нет липкого сеанса, откроет мир головных болей.

Скажем, first.jsp обновляет некоторое значение в определенном атрибуте сеанса, а second.jsp выполняет чтение этого же атрибута сеанса. Вы можете настроить Tomcat для репликации данных сеанса на все серверы кластера, но эта репликация не происходит мгновенно. Что делать, если начальный запрос для first.jsp обрабатывается server1 и через 1 наносекунду после его завершения, тот же посетитель делает запрос second.jsp, который в вашей нелипкой среде обрабатывается server2. Поскольку репликация не мгновенная, есть ли у вас какой-либо способ узнать, читаете ли вы самые последние данные сеанса? Вам нужно добавить какую-то логику для синхронизации ваших чтений по кластеру? Это станет огромной болью.

Настройка сеансовой близости/липких сеансов устраняет эту головную боль; имея все запросы с одного и того же клиентского сервера одним и тем же node, вам не нужно беспокоиться о том, является ли этот node актуальным к тому моменту, когда он обрабатывает запрос? " Когда node терпит неудачу, клиент может по-прежнему отказываться от другого node в кластере, который имеет копию данных сеанса, но с липкими сеансами это становится редким случаем, а не нормой.

Есть еще одна причина, по которой вам нужны липкие сеансы: загрузка между узлами в кластере. Если запрос в сеансе может быть обработан любым node, то это означает, что у вас есть универсальная репликация, настроенная в кластере (это означает, что данные сеанса узла1 реплицируются в node2, node3,..., node N, данные сеанса узла 2 реплицируются на узел1, узел3,... нет N и т.д.). Репликация общего доступа может стать пропускной и ресурсоемкой, когда кластер станет больше, потому что каждое добавление к кластеру означает еще один node, который должен связываться с каждым другим одиночным node в кластере.

Альтернативой этому является наличие node данных, реплицированных только для нескольких "приятелей" в кластере, поэтому в случае неудачи node данные доступны в другом месте, но без каждого отдельного node, который должен иметь копия. В этом случае вы должны настроить кластер так, чтобы узел1 реплицировал данные на узлы 2 и 3, node 2 он реплицировал данные на узлы 3 и 4 и т.д., Образуя цепочку. В этом случае добавление дополнительных узлов в кластер не приводит к тому, что количество связей между узлами увеличивается быстро, как это происходит в схеме "все-ко всем".