#mysql #ruby-on-rails #ruby #session #redis
#mysql #ruby-on-rails #ruby #сессия #redis
Вопрос:
Каков наилучший метод для хранения данных сеанса в rails? Очевидно, это зависит от ваших потребностей, но каковы ключевые факторы, влияющие на решение, и каковы идеальные хранилища сеансов для различных сценариев?
Ответ №1:
Безопасность должна вызывать беспокойство. Имейте в виду, что все, что хранится на стороне клиента (например, файлы cookie, параметры отправки формы, параметры получения и т.д.), Может быть изменено с помощью прокси-серверов браузера. Итак, всегда проверяйте все, что возвращается через браузер. Вы могли бы зашифровать значения в файлах cookie или сформировать параметры POST как wel. Также, как упоминал Стив, файлы cookie обычно следует использовать только для небольших значений.
Метод на основе файлов по умолчанию очень хорош, если вы не собираетесь работать на кластере серверов, или если вы собираетесь, если вы можете допустить, что сеансы пользователей будут потеряны, если сервер выйдет из строя (им придется снова входить в систему). Для подавляющего большинства приложений это вполне приемлемо. Вам нужно настроить ваш балансировщик нагрузки для «липких сеансов», что означает, что данный пользователь привязан к одному серверу. Однако это может немного усложнить балансировку нагрузки, поскольку иногда вы обнаружите, что многие пользователи привязаны к одному серверу, в то время как другой сервер простаивает там.
Если вам требуется общее состояние сеанса по всему кластеру, у вас есть пара основных вариантов. Если ваш трафик не экстремален и вы можете справиться с небольшой дополнительной задержкой, то вы можете сохранить информацию о сеансе в базе данных. Пока ваша база данных работает, данные сеанса не будут потеряны. Если ваша база данных не работает, данные сеанса, вероятно, являются наименьшей из ваших забот. Если ваше приложение имеет очень высокий трафик или невероятно критично к производительности, то лучше всего использовать распределенный кэш, такой как memcached. Однако это дополнительная «инфраструктура», которую вам придется поддерживать и отслеживать. Даже если memcached распространяется, это все равно дополнительная точка отказа, которую вы добавляете в среду вашего приложения. Итак, не относитесь к этому легкомысленно, если вам это действительно не нужно.
Короче говоря, я бы сказал, что подход к хранению сеансов на основе файлов по умолчанию, вероятно, вполне приемлем для более чем 90% приложений.
Комментарии:
1. мы уже используем хранилище БД и обеспокоены дополнительной задержкой — кажется, добавляется около 100 мс к запросам … однако memcache может завершиться сбоем, и я не хочу принудительно входить в систему. redis кажется немного лучше, учитывая его способность периодически записывать на диск — но у меня нет опыта работы с redis, и я не уверен, стоит ли заменять им memcache как для кэширования, так и для хранения сеансов. шире, чем исходный вопрос, но он есть….
2. «Чтобы предотвратить подделку хэша сеанса, из сеанса вычисляется дайджест с секретом на стороне сервера и вставляется в конец файла cookie». guides.rubyonrails.org/security.html.
3. 100 мс кажется чрезмерным. Вы настроили свое хранилище сеансов в базе данных? Каково соотношение чтения и записи информации о сеансе? Вы могли бы сохранять доступ к базе данных при каждой записи, но затем кэшировать в memcached таким образом, чтобы, если он есть, вы не запрашивали базу данных, а просто запрашивали непосредственно из кэша. Если сеанс не существует в кэше (возможно, потому, что сервер умер), запросите базу данных для заполнения кэша. Используйте sticky sessions до тех пор, пока сервер остается активным, так что, как правило, информация о сеансе находится на определенном сервере…
Ответ №2:
Почти для каждого сценария файлы cookie являются лучшими. Они просты в том смысле, что зависят только от того факта, что серверный процесс отвечает и что браузер пользователя работает так, как это делают браузеры.
Файлы cookie не подходят для хранения больших объемов данных или данных, которые должны быть скрыты от пользователя, но это просто означает, что вы не должны помещать такие вещи в сеанс. Обычно это не проблема, если вы помните об этом ограничении.
Комментарии:
1. проблема с файлами cookie заключается в возможности для опытного пользователя изменять значения. также каждый запрос отправляет данные туда и обратно, что кажется излишним. вместо этого я бы предпочел отправить ключ для поиска данных.
2. @ChrisH — «Чтобы предотвратить подделку хэша сеанса, из сеанса вычисляется дайджест с секретом на стороне сервера и вставляется в конец файла cookie». guides.rubyonrails.org/security.html . Поскольку данные сеанса должны быть небольшими, отправка их туда и обратно не является проблемой. Кроме того, cookie отправляется с сервера только тогда, когда он изменился.