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

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

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

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

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

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

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

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

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

Прочитайте этот URL для хороших советов по проектированию кластера при включении репликации сессий.

Память

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

Соображения по коду

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

Липкие сессии

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

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