Кластеризация веб-приложения Java EE - Параметры?

Question

У меня есть веб-приложение, развернутое на три сервера под управлением Apache, Tomcat и балансировщик нагрузки перед ними. Теперь я думаю о их кластеризации.

Вот варианты обычные варианты и мои ограничения, я отдаю себе отчет:

1. сериализации на основе Session кластеризация: В моем случае, приложение использует большое количество объектов в сессии. Поэтому я бы предпочел не идти с этим решением. Кроме того, в ближайшем будущем количество серверов, вероятно, увеличится до более пяти.

2. Терракота: Звучит интересно, но покупка лицензии на предприятие не является вариантом.

3. Сделать заявку без гражданства: Звучит соблазнительно, хотя это немного работа. Я хотел бы услышать некоторые рекомендации по дизайну и опыт на нем.

Другие идеи?

Моя основная цель - Отказоустойчивость.

Answer 1

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

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

• Хранить все в базе данных. Может быть, сериализован как blob. Вам нужно сэкономить эти капли при тайм-аутах сеанса. Такие серверы приложений, как WebSphere, имеют такую ​​возможность.
• Используйте некоторую репликацию памяти-памяти. Опять же, придется потратить несколько процентов/сериализацию. Вы можете обменять частоту этой репликации против возможности потери последних обновлений сеанса.

В любом случае вы нацеливаетесь на «близость сессии»: запросы пользователя по умолчанию переходят к одному и тому же члену кластера, эффектно, что их «домашний» экземпляр действует как кеш с записью.

Я не знаю, что предусмотрено в вашей среде, в идеале у вашего провайдера сервера должны быть встроенные средства управления сессиями - написание этого материала, ваше «я» не является полностью тривиальным.

Answer 2

Я понимаю, что вы в настоящее время загружаете нагрузку на 3 сервера, поэтому для меня уже выполняется кластеризация (часть масштабируемости), и я не уверен, что именно вы подразумеваете под их «кластеризацией». Вы имеете в виду выйти за рамки прозрачного провала?

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

Это полезно, если вы не хотите, чтобы ваши пользователи теряли свою сессию, если один экземпляр падает.Если вы действительно хотите этого, вы будете нуждаться в «постоянный сеанс» (но имейте в виду, что это имеет цену исполнения), Tomcat предлагает several way осуществить это:

1. с помощью сеанса упорства и сохранения сессии в общий файл system,
2. с использованием сохранения сеанса и сохранения сеанса в общей базе данных,
3. с использованием репликации в памяти.

Для этого потребуется какая-то настоящая скамейка, но, лично, репликация в памяти - мое предпочтительное решение (лучшие показатели). Избегайте сериализации в базу данных любой ценой (плохие результаты из моего опыта).

Терракота: Звучит интересно, но покупка лицензии на предприятие не является вариантом.

Я думаю, вы имеете в виду их кластерное решение на уровне JVM. Кластеризация JVM под приложением (и кластеризация самого приложения) - это решение IMHO, когда приложение не может быть легко сгруппировано? Но зачем вам это делать с сервером приложений, предлагающим такую ​​функцию?

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

Вы хотите сказать, что не используете HTTPSession? Если да, то почему? с какими проблемами вы сталкиваетесь HTTPSession? Зачем вам это делать?

---

Если честно, то, что вы пытаетесь достичь, мне не ясно. У вас уже есть масштабируемое решение (по вертикали и по горизонтали), ни одна точка отказа (кроме балансировки нагрузки, но хорошо ...), и очень немногие приложения (например, жизненно важные приложения, финансовые приложения) действительно нуждаются в прозрачной отказоустойчивости (в другими словами, многие могут жить без). Более того, прозрачная отказоустойчивость имеет реальную стоимость с точки зрения производительности и/или аппаратного обеспечения, которые не следует пренебрегать. Итак, настоящие вопросы: ваше предприятие потеряло столько денег, когда пользователь теряет свою сессию? Это критически/часто? Это оправдывает расходы на реализацию прозрачной отказоустойчивости?

Answer 3

Терракота: Звучит интересно, но покупка лицензии на предприятие не является вариантом.

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

Для начала, зайдите сюда: http://www.terracotta.org/web/display/orgsite/Web+Sessions