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

Question

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

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

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

Редактировать: Чтобы быть более конкретным (и в качестве примера), я имею в виду сеансы на стороне сервера веб-приложений Java в среде контейнера сервлетов.

Answer 1

У вас есть ссылка на точное определение «распределенной сессии», которое вы имеете в виду?

Я думаю, что ваша идея заключается в том, что клиент (например, браузер) и сервер (например, механизм сервлетов) и состояние сеанса распределены в том смысле, что ответственность за сеанс распределяется между клиентом и сервером - так, например, клиент должен отправить конкретный файл cookie с каждым запросом, и сервер должен определить, какой сеанс принадлежит клиенту.

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

Простой случай: сервер сохраняет состояние в базе данных после каждого запроса. Довольно надежный, но дорогостоящий (каждый раз записывает DB), достаточно масштабируемый, может иметь много копий сервера. Разработчик приложения должен убедиться, что состояние может сохраняться - это часто означает, что классы должны быть Serializable. И если вы ставите много вещей на сеанс, это становится дорогим!

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

Итак, распределите сеанс: на некоторых серверах приложений есть умные схемы распределения, чтобы передать сеанс другим экземплярам. Часто это считается более дешевым, чем БД, на практике это может и не быть. Еще раз разработчик приложения должен сделать сеанс сериализуемым. Обычно вам по-прежнему нужна хорошая близость к клиенту/серверу, поэтому вы чаще всего нажмете один и тот же сервер, что приводит к меньшему копированию сеанса.

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

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

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