Я использую сеансы в PHP для отслеживания входа пользователя в систему. Я не использую его для хранения каких-либо других данных о пользователе; по сути, это похоже на проверку хэш-таблицы, чтобы проверить, прошел ли аутентификация пользователя.
Можно ли использовать redis вместо собственных PHP-сессий?
Мне интересны производительность, масштабируемость и безопасность (на самом деле не проблема с сложностью кода).
Можно ли использовать redis вместо собственных PHP-сессий?
Производительность - сеансы PHP лучше. Они будут быстрее, чем Redis, потому что его чтение из ОЗУ, а не что-то по сети.
Масштабируемость. Повторные сеансы лучше. Сессии PHP работают только на одной машине. Если вам нужно несколько машин для обслуживания запросов, вам придется внедрять липкие сеансы. С Redis несколько машин могут делиться состоянием сеанса. Пользовательский запрос может без проблем работать на любом сервере.
Долговечность. Если по какой-то причине сбой веб-сервера, вы потеряете все состояние сеанса. С помощью Redis вы можете использовать различные параметры сохранения. Вы можете гарантировать, что вы не потеряете информацию о сеансе, даже если конкретный сервер Redis не работает
Безопасность. Вы можете добиться большой безопасности с помощью обоих подходов, и вы можете полностью испортить использование обоих подходов. При прочих равных условиях, я бы сказал, что сеансы PHP будут немного более безопасными, потому что есть еще одна проблема, о которой нужно беспокоиться.
Забастовкa >
Использование чего-то вроде Redis для хранения сеансов - отличный способ повысить производительность балансированных серверов.
Например, на веб-сервисах Amazon у балансировщиков есть так называемые "липкие сеансы". Это означает, что когда пользователь сначала подключается к вашему веб-приложению, например, при входе в систему балансировщик нагрузки выберет один из ваших серверов приложений, и этот пользователь будет продолжать обслуживаться с этого сервера до выхода из приложения. Это связано с тем, что сеансы, используемые PHP, например, будут храниться на сервере приложений, который они сначала начнут использовать.
Теперь, если вы используете Redis на отдельном сервере, настройте свой PHP на каждом из серверов приложений, чтобы сохранить его в Redis, вы можете отключить эти "липкие сессии". Это означает, что любой из ваших серверов может получить доступ к сеансам, и, следовательно, пользователь будет обслуживаться с другого сервера с каждым запросом в вашем приложении. Это в конечном счете позволяет более эффективно использовать настройку балансировки нагрузки.
Вы хотите, чтобы обработчик сохранения сеанса был быстрым. Это связано с тем, что сеанс PHP блокирует все другие параллельные запросы от одного и того же пользователя до завершения первого запроса.
Существует множество обработчиков, которые можно использовать для сеансов PHP на нескольких серверах: файл с NFS, база данных MySQL, Memcache и Redis.
Метод базы данных (с использованием InnoDB) был самым медленным в моем опыте, а затем File w/NFS. Основными факторами являются блокировка и запись. Memcache и Redis обеспечивают аналогичную производительность и, безусловно, являются лучшими альтернативами, поскольку все операции находятся в ОЗУ. Redis - мой выбор, потому что вы можете включить жесткость диска, а Memcache основан только на памяти.
Я объясню Redis Sessions в PHP с Kohana, если вы хотите получить более подробную информацию. Вот наша панель управления для управления ключами Redis:
Я действительно не думаю, что вам нужно много беспокоиться о сеансах, если вы не получите МАССИВНЫЕ количества трафика, PHP отлично справляется с сеансами, и если вы храните только эти небольшие данные, это должно быть хорошо даже при большом количестве запросов и о производительности он должен быть близок, поскольку redis не является родным для PHP.
С 10 тыс. пользователей, если каждый пользователь использует как 1 кб данных сеансов, он будет потреблять 10 000 КБ или 10 Мб, что мало; PHP достаточно умен, чтобы использовать достаточно хорошую структуру данных для хранения и быстрой записи и чтения этих значений. Проблема заключается в том, что данные сеанса слишком велики или по какой-то причине сервер потребляет слишком много ресурсов, считывая данные сеанса, но это обычно, если они слишком большие.