Производительность кластеризации / балансировки нагрузки Tomcat в производственной среде
У меня есть некоторые сомнения по поводу производительности кластеризации и управления сессиями в среде с балансировкой нагрузки. Вот мои вопросы:
- Каковы недостатки липких сессий и репликации сессий. Кластер будет содержать 4 узла, но можно ожидать много одновременных пользовательских сессий.
- Какова нагрузочная способность обоих решений?
- Кто-нибудь использовал их в производственной среде?
- Как насчет масштабируемости?
- Если используются постоянные общие сеансы - где хранить состояние для достижения возможно быстрого и стабильного решения?
- Есть ли у вас опыт большого сеанса совместного использования сеансов (во внешней памяти, базе данных и т. Д.)?
Спасибо за любой совет
2 ответа
- Недостаток sticky-сессий заключается в том, что с ростом числа узлов (в диапазоне> 100, > 1000) вероятность сбоя увеличивается. Тогда предпочтительно, чтобы не имело значения, какой узел обслуживает запрос. Однако есть проблемы, которые должны решаться с помощью липких сессий по-разному, что, конечно, зависит от требований и приложения (примеры - синхронизация сессий, предотвращение двойной отправки, перенаправление после публикации и т. Д.). Чаще всего я предпочитаю использовать липкие сессии, если количество узлов ограничено. Для 4 узлов лично я бы рекомендовал использовать липкие сессии.
- Мы использовали sticky-сессии и репликацию сессий через http://code.google.com/p/memcached-session-manager в производственных средах. memcached-session-manager был разработан во время повторного запуска tchibo.de (одного из крупнейших сайтов электронной коммерции в Германии) с целью повышения производительности и масштабируемости.
- Мы выбрали sticky-сессии для этого приложения
- из-за лучшей производительности
- требования клиента выбрали липкие сессии
- использованный веб-фреймворк лучше подходил для липких сессий.
Это не то или это, если приложение требует обоих, то вы должны использовать оба. Кластеризация предназначена для управления нагрузкой, в то время как сходство сессий используется для защиты данных пользователя в случае сбоя на узле.
Приведите этот пример, если вы работаете с узлом, и нет никакого липкого сеанса, и ваш узел падает, кластеризация обеспечит вам просмотр страницы, но ваш текущий рабочий сеанс будет потерян.