Каковы недостатки репликации сеансов на Tomcat?

Я пытался решить, что лучше в режиме обратного прокси-сервера Tomcat + Apache для репликации сеанса. Что более распространено при развертывании? репликация сеанса или сеанс палки? Существуют ли какие-либо недостатки для репликации сеанса?

Спасибо

Ответ 1

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

Производительность

Основным недостатком будет производительность. Реплицированные сеансы включают копирование данных сеанса на все серверы в кластере. Чем больше серверов у вас в кластере, тем дополнительные дополнительные накладные расходы.

Tomcat помогает с этими накладными расходами, определяя два режима репликации сеанса.

DeltaManager (по умолчанию) и BackupManager

Из этого URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

Используя приведенную выше конфигурацию, включить всенаправленную репликацию сеанса использование DeltaManager для репликации дельта. Все мы имеем в виду что сеанс реплицируется на все остальные узлы кластера. Это отлично работает для меньшего кластера но мы не рекомендуем его для более крупных кластеров (много узлов tomcat). Также при использовании дельта-менеджера он будет реплицировать на все узлы, даже узлы которые не имеют приложения развертывается.

Чтобы обойти эту проблему, вы захотите использовать BackupManager. Этот менеджер реплицирует данные сеанса в одну резервную копию node и только узлам, которые имеют приложение развернуто. Нижняя сторона BackupManager: не совсем как битва проверен как менеджер дельта

Прочтите этот URL, чтобы получить полезные советы по дизайну для кластера, если включить репликацию сеанса.

Память

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

Кодовые соображения

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

Sticky Sessions

Учитывая эти соображения, это фактически зависит от критичности вариантов использования. Если вы идете на липкие сеансы в одиночку, тогда есть вероятность потери пользовательских данных во время критического путешествия.

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

Ответ 1

Ответ 2