Совместное использование данных Сеанса HTTP в Пассажире/Стойке - Какова Лучшая Существующая практика?
Моей компании распределили стоящее с клиентом веб-приложение через несколько серверов в целях выравнивания нагрузки и отказоустойчивости. Приложение записано в Ruby (Стойка, работающая при Пассажире), и аутентификация к приложению обрабатывается через cookie Сеанса HTTP.
Мы в настоящее время используем базу данных SQL, чтобы хранить данные сессии (копирующий его как часть нашей стандартной репликации баз данных), однако это решение не идеально, поскольку наша база данных SQL является Пост-ГРЭС и не поддерживает мультиосновные операции (во время отключения электричества обслуживания на основных зарегистрированных пользователях базы данных, может проверить их сессии по ведомому устройству, но новые пользователи не могут войти в систему). Издержки SQL-запросов для каждого хита страницы также не оптимальны.
Я хотел бы знать то, что люди практических решений в настоящее время используют в производстве.
Идеально мы ищем:
Хранилище сеанса совместной работы
Пользователи вошли в системуServer Aдолжен смочь прозрачно переместиться вServer Bне имея необходимость входить в.Хорошее дублирование
Потеря единственного сервера не должна терять состояние сеанса.Низко наверху
Как минимум "менее интенсивный, чем SQL-запрос для каждого хита страницы".
Пока что наиболее перспективным решением, которое мы нашли, является rack-session mongo . Это, в сочетании с репликацией MongoDB, должно соответствовать как общему хранилищу сессий, так и требованиям резервирования/неисполнения.
Мы начинаем тестирование, чтобы проверить, соответствует ли оно требованию "низких накладных расходов", но оно кажется многообещающим и в этом отношении.