Поддержание состояния на сервере приложений или в базе данных? - PullRequest
Новая
       27

Поддержание состояния на сервере приложений или в базе данных?

5 голосов
/ 27 января 2010

REST поддерживает веб-приложения без состояния клиента на сервере. Известный пример корзины покупок переведен на ресурс, который обычно находится в базе данных.

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

Каковы преимущества и недостатки двух подходов?

Ответы [ 4 ]

3 голосов
/ 27 января 2010

Хранение сеансов на сервере приложений будет работать только в том случае, если:

  • Ваши клиенты всегда подключаются к одному и тому же серверу приложений (также известному как "сходство сеансов")
  • Все узлы кластера приложений всеиспользуйте общую точку монтирования (nfs и т. д.) для спулинга сеансов

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

Другой подход, который следует рассмотреть, - это использование службы, такой как memcached .Это будет работать в любом случае.

2 голосов
/ 27 января 2010

В целом:

База данных

  • более надежно и выдержит перезапуск приложения / сервера
  • может быть распределен между серверами с балансировкой нагрузки без необходимости работать с «липкими» сессиями
  • медленнее для доступа

In-Memory (нераспределенный компонент с состоянием)

  • Быстрое хранение и поиск
  • Меньше кода
  • Будет потеряно, если приложение / сервер перезапустится

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

1 голос
/ 27 января 2010

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

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

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

В противном случае: просто сохраните его в сеансе.

Есть ли у вас экстремальные требования к масштабированию (например, переполнение стека или сайты с еще большим объемом трафика)? Найдите способ не использовать базу данных.

Это правда, что база данных часто является узким местом. Но правильно настроенная база данных должна нормально обрабатывать пару байтов данных сеанса. Более сложные данные и запросы - вот что снижает производительность.

0 голосов
/ 27 января 2010

Все остальные предметы являются хорошими предложениями.Еще одно: не используйте состояние сеанса, если оно вам абсолютно не нужно.

Хранение сеанса в базе данных (как правило) является плохой идеей по нескольким простым причинам:

  1. Типичное использование сеанса - избавление от необходимости загружать общие данные с сервера базы данных несколько раз.Если сеанс хранится на сервере базы данных, то, на самом деле, вы действительно мало чего добились.

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

По моему опыту выгораздо лучше обслуживать данные из сервера базы данных, когда они вам действительно нужны.В большинстве случаев люди помещают все виды короткоживущих данных в сессию просто потому, что думают, что решают проблему с производительностью, а на самом деле они ухудшают ее.

Более того, если вы ограничите объем данных (произнесите имя пользователя, имя или что-то в этом роде), затем вы можете сохранить это на стороне клиента с зашифрованными файлами cookie и вообще не беспокоиться об этом.

MemCache - один из вариантов;но опять же, я серьезно посмотрю на использование вашей базы данных и выясню, сможете ли вы сначала настроить параметры запросов и схем.

...