С технической точки зрения в PHP есть встроенный механизм сессий (для борьбы с Альцгеймером), который позволяет автоматически (средствами PHP) записывать пользователю в cookie идентификатор сессии, а данные, относящиеся к этой сессии, хранить где-то у себя.
Где именно - зависит от параметра session.save_handler, и по умолчанию это файлы.
С файлами у нас сразу горсть проблем:
- Система сразу попадает под вид нагрузки "случайная запись/чтение мелких файлов". Если у вас SSD, это не так критично, а обычные жесткие диски сильно страдают.
- Даже самый маленький файл сессии занимает на диске не меньше, чем размер блока. Таким образом, при блоке 4Кб, даже если вы записали в сессию 1 байт, на диске будет занято 4Кб. И 1024 сессии по 1 байту займут на диске не 1Кб, а 4Мб.
- По умолчанию все файлы сессий складываются в одну папку, без вложенности. Соответственно, следует сразу спросить себя: не пострадает ли файловая система от наличия в одной папке пары миллионов файлов.
- Есть встроенная возможность разложить файлы сессий по дереву папок, но при этом выключится автоматическая очистка файлов истекших сессий (это, кстати, очередной забавный нюанс, о котором не все знают).
- Автоматическая же очистка файлов истекших сессий сильно нагружает диск и производится в том же процессе, что и обслуживание клиентского запроса. То есть каждый 100-й (по умолчанию) запрос будет отдаваться существенно медленнее остальных 99.
- А еще хранение файлов на диске исключает балансирование нагрузки между разными серверами. Потому что следующий запрос обслуживать будет соседний сервер, а у него в файлы сессии ничегошеньки не записано.
К счастью, взрослые дядьки уже написали для нас другие методы хранения данных сессий. Например, модуль redis для PHP предоставляет нам возможность хранить данные в базе данных Redis.
Это позволяет нам решить массу проблем одним махом (натурально, достаточно изменить session.save_handler и дописать параметры для соединения с Redis).
- Соединение с Redis можно делать по сети. Сразу появляется возможность балансировать нагрузку на сервера с PHP.
- А еще можно для балансировки размножить сам Redis штатными средствами, то есть все вообще замечательно.
- Redis тоже имеет накладные расходы на хранение данных, но не такие большие.
- Redis легко справляется с огромным числом ключей (это база данных "ключ-значение", где ключом выступает идентификатор сессии, а значением - её данные), их натурально можно записывать миллиарды, он и не почешется.
- Нет необходимости включать в клиентский процесс сборку мусора. Сборка мусора при хранении в файлах включает обход всех файлов, чтение их, и проверку, не истекли ли связанные с ними сессии. В случае хранения в redis, ключу сразу присваивается время жизни, и можно положиться на встроенный в Redis механизм инвалидации. Нагрузка будет размазана равномерно, и нет необходимости проверять все ключи, раз Redis уже знает, какие у них сроки годности.
К сожалению, тут опять есть небольшой нюанс, о котором следует знать. По умолчанию сессия в Redis не блокируется, поэтому одновременный доступ к данным может привести к их искажению или потере. На этот счет есть неплохая статья, показывающая как люди это обходят.
Проблема хранения сессий - одна из базовых, поэтому не стоит писать свой обработчик. Достаточно выбрать из уже имеющихся. Тем более, чем было бы разумно вознестись над функциями ядра в более высокий уровень абстракции.
Свои нюансы связаны не только с хранением данных сессии на сервере, но и с хранением самого идентификатора сессии у клиента.
Этот идентификатор генерируется автоматически и хранится в cookies пользователя.
Бояре помнят времена, когда cookies поддерживались не всеми клиентскими браузерами. С тех времен сохранился механизм передачи идентификатора через формы и ссылки. По умолчанию отключен, но желающие могут изучить документацию к параметрам семейства session.use_trans_sid. После этого крайне рекомендуется почитать о такой вещи, как фиксация сессии, из-за которой этот параметр и был по умолчанию отключен.
С cookies связана еще одна популярная проблема.
Разработчик, не прочитавший руководство целиком, может возжелать, чтобы его сессии хранились, скажем, неделю. Он ставит подходящее значение в session.gc_maxlifetime и радуется. Ровно до тех пор, пока не выясняется, что сессия куда-то делась.
Оказывается, надо не забыть обязательно настроить соответствующим образом другой параметр: session.cookie_lifetime. По умолчанию, в нем стоит 0, то есть cookie хранится до закрытия браузера. Как только cookie из браузера пропадает, возникает проблема: сервер продолжает считать данные валидными, но браузер забыл идентификатор, по которому их можно достать.
Это очень частая проблема, и на неё стоит обратить особое внимание.
И последнее.
Если "мсье знает толк в извращениях", можно переопределить функцию, создающую идентификатор сессии. Например, вместо случайного md5 порождать подписанный токен с гарантированной уникальностью.
В обычной жизни пригодится единицам.
