Назад | Перейти на главную страницу

Производительность кластеризации / балансировки нагрузки Tomcat в производственной среде

У меня есть некоторые сомнения в производительности кластеризации и управления сеансами в среде с балансировкой нагрузки. Вот мои вопросы:

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

Спасибо за любой совет

Недостатком sticky-сессий является то, что с ростом количества узлов (в диапазоне> 100,> 1000) вероятность сбоя увеличивается. Тогда желательно, чтобы не имело значения, какой узел обслуживает запрос. Однако есть проблемы, которые необходимо решать с помощью прикрепленных сеансов по-разному, что, конечно, зависит от требований и приложения (примеры: синхронизация сеанса, предотвращение двойных отправок, перенаправление после публикации и т. Д.). Чаще всего я предпочитаю использовать липкие сеансы, если количество узлов ограничено. Лично для 4 узлов я бы рекомендовал использовать липкие сеансы.
Мы использовали липкие сессии и репликацию сессий через memcached-сеанс-менеджер в производственных средах. memcached-session-manager был разработан во время перезапуска tchibo.de (одного из крупнейших сайтов электронной коммерции в зародыше) с целью повышения производительности и масштабируемости.
Мы выбрали липкие сессии для этого приложения
- из-за лучшей производительности
- требования клиентов выбрали липкие сеансы
- используемый веб-фреймворк лучше подходил для липких сессий.

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

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