Я знаю людей, которые использовали Memcached для этого - это очень быстро, конечно, намного быстрее, чем база данных, и построено для обработки намного большего количества параллелизма.
Основным недостатком хранения в памяти является то, что все ваши данные сеанса будут стерты, если / когда вы перезапустите демон. По моему опыту, memcached отлично работает, и мне никогда не приходилось перезапускать его из-за сбоя, но важно учитывать, что ваши системные администраторы не привыкли работать таким образом или ваши системы часто обновляются. Это также зависит от того, является ли приемлемой потеря всех ваших пользовательских сессий раз в месяц или год (т. Е. В электронной коммерции, вероятно, руководству это не понравится).
Очевидное решение, если это так, состоит в том, чтобы перейти к одной из множества дисковых баз данных NoSQL / хеш-таблиц, таких как MemcacheDB , которая основана на Memcached. Или посмотрите: CouchDB , MongoDB и т. Д. Каждый из этих демонов (включая Memcached) также намного менее сложен, когда речь идет о настройке производительности, чем MySQL (где все виды вещей, таких как key и сортировать буферы, кеш запросов и т. д. необходимо настраивать в зависимости от установки / использования) - я имею в виду, что с Memcached не нужно ничего делать, кроме как выделить память и запустить ее.
Лично я фанат использования более быстрого, более подходящего (не SQL) хранилища для временных вещей, таких как сеансовые ключи, но если ваша база данных не загружена, и вы не ожидаете, что это будет, единственное, что вы потеря при хранении сеансов в базе данных состоит в том, что это немного медленнее, поэтому пользователи видят немного большую задержку.
Какой бы путь вы ни выбрали, я предлагаю вам написать свой код управления сеансом таким образом, чтобы механизм хранения был просто слоем, и вы могли безболезненно переключаться в другой механизм хранения. Вы не хотите перекодировать свое приложение, если обнаружите, что memcached или что-то другое не работает, и вы хотите попробовать что-то еще. Например, я однажды написал систему кеширования для кластерного приложения CMS, которое использовало memcached для кеширования различных страниц и объектов, но когда демон не был доступен, он отказывался от чередования бэкэндов, которые кэшировали бы в общую память или диск на диске. отдельные веб-серверы. (В вашем случае вам не обязательно нужен автоматический переход на другой ресурс, просто возможность передумать о бэкенде.)
Я упомянул MemcacheDB, поскольку он использует протокол Memcache, поэтому в MemcacheDB очень легко поменять местами MemcacheDB или наоборот.