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

Question

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

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

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

Answer 1

Как уже отвечали на SF:

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