Имеете ли вы в виду точное определение «распределенного сеанса»?
Я думаю, что ваша идея состоит в том, что есть клиент (например, браузер) и сервер (например, механизм сервлета), а состояние сеанса распределяется в том смысле, что ответственность за сеанс распределяется между клиентом и сервером - так например, клиент должен отправлять определенный файл cookie с каждым запросом, а сервер должен определять, какой сеанс принадлежит какому клиенту.
Существуют фундаментальные проблемы, которые необходимо решить: согласованность, надежность и масштабируемость, из-за наличия состояния сеанса вы затрудняете одно или другое, либо оба.
Простой случай: сервер сохраняет состояние в базе данных после каждого запроса. Довольно надежный, но дорогой (запись в БД каждый раз), достаточно масштабируемый, может иметь много копий сервера. Разработчик приложения должен убедиться, что состояние может сохраняться - это часто означает, что классы должны быть сериализуемыми. И если вы добавите много материала в сеанс, это будет дорого стоить!
Так что держите это в памяти: давайте не будем сохранять сеанс, сохраняем его в памяти. Это работает лучше за счет надежности, теперь, если мы теряем сервер, мы теряем сеанс. И мы должны убедиться, что каждый запрос от клиента направляется к одному и тому же экземпляру сервера, поэтому масштабируемость сложна. Мы не можем просто перенести запросы на другие копии сервера, у них не будет сеанса.
Итак, распределите сеанс: некоторые серверы приложений имеют умные схемы распределения для передачи сеанса в другие экземпляры. Часто считается, что это дешевле, чем БД, на практике это может быть не так. Еще раз разработчик приложения должен сделать сериализуемую сессию. Обычно вам все еще нужно хорошее сходство клиент / сервер, поэтому вы чаще всего используете один и тот же сервер, что приводит к меньшему количеству копий сеанса.
Часто, что нам действительно нужно сделать, это стать избирательным. Не весь сеанс важен. Мы бы не хотели потерять корзину, но список того, на что мы только что посмотрели? Предположим, этот список был бы немного устаревшим, если бы это имело значение.
Отсюда моя общая рекомендация: не используйте состояние сеанса для вещей, которые вас действительно волнуют, не используйте состояние сеанса в качестве общего основания для дампинга. В целом, разработчики гораздо лучше помещают вещи в сессию, чем снова убирают. Большие (больше чем k или два) постоянные сессии являются серьезной проблемой.
Так что, как правило: сохраняйте важные вещи в БД, подумайте о том, чтобы поместить некоторые вещи в куки (эффективно возложить ответственность на клиента), добавить в сеанс только те вещи, которые можно легко воссоздать. Тогда вы можете просто полагаться на простую сессионную привязку и отсутствие сохранения / распределения между экземплярами сервера.