Какое хранилище сеансов наиболее надежно в PHP: Memcache, база данных или файлы? [закрыто]

10

Какой самый лучший и самый безопасный способ обработки PHP-сессий. Это лучший способ хранить сессии в:

  1. База данных (более надежная, но узкое место, медленная скорость, не подходит для сайтов с высоким уровнем использования базы данных)?

  2. Memcache (супер быстрый, но распределял больше проблем с безопасностью, шансы на потерю данных при перезапуске сервера и шансы на потерю данных, когда кеш заполнен)?

  3. Файлы (опция по умолчанию, я полагаю, медленная, поскольку она считывает и записывает из файлового ввода-вывода, снижает безопасность и т. Д.).

Какой метод самый лучший? Каковы проблемы и хорошие стороны каждого из этих подходов?

user1179459
источник
2
Я считаю, что вы должны указать, используете ли вы только один компьютер или приложение распространяется, так как это сильно повлияет на ответы.
Арсений Мурзенко
1
@haylem это самое подходящее место, чтобы задать этот вопрос, это не вопрос программирования, а концептуальная проблема программирования,
user1179459
3
Это действительно плохой вопрос, потому что «лучшее» зависит от ваших конкретных обстоятельств. «Лучшее» для Facebook, вероятно, не такое же «лучшее» для вашей личной домашней страницы.
GrandmasterB
1
@GrandmasterB Я знаю, именно поэтому я четко спросил: «Каковы проблемы и хорошие стороны каждого из этих подходов?» выяснить, какой из них лучший для меня.
user1179459

Ответы:

6

Лучше всего хранить в Memcached, поскольку мы можем легко решить другие проблемы (размер кэша, безопасность и т. Д.)

Facebook - потребитель # 1 memcached. Пожалуйста, прочитайте, если вы заинтересованы: http://www.facebook.com/note.php?note_id=39391378919

Как решить другие вопросы?

Г-н Махбубур Рахман
источник
4

Для подавляющего большинства повседневных приложений хорошо хранить сессии в базах данных. Объем и уровень параллелизма, который может обрабатывать сервер SQL, будет более чем достаточным. Ключ в том, чтобы каждая запись была небольшой по размеру и регулярно очищала ненужные строки. И правильная индексация, конечно.

Файловая система - я никогда не видел необходимости делать это. Я предпочитаю простоту управления строками в таблицах, а не тысячи маленьких файлов. Кроме того, вы не можете запрашивать файлы, если хотите копаться в статистике сеансов.

Имейте в виду, с PHP легко заменить обработчики сеансов. Таким образом, вы можете начать с одного формата хранения и перейти на другой без особых хлопот.

GrandmasterB
источник
4

Как насчет использования механизма хранения MEMORY в MySQL?

Это не так быстро, как Memcache, но имеет преимущество в том, что вы можете использовать обычный SQL, а также использовать обычный механизм хранения, когда он не понадобится, и переключаться на MEMORY, когда число пользователей / запросов растет.

Я использую его для хранения больших объемов статистических данных в веб-приложении, которое часто меняется, поэтому оно не используется для обработки сессий, но я думаю, что оно должно хорошо подходить для этой цели.

onlineapplab.com
источник
3

В этом сообщении блога показаны результаты сравнения производительности различных механизмов хранения сессий с Magento, и они, похоже, пришли к выводу, что до 75 одновременных пользователей разницы в производительности между ними нет.

Я думаю, что на этих уровнях (у них было около 5 транзакций в секунду, что составило бы около 430 тыс. Обращений за 12-часовой период) накладные расходы во всем остальном преобладают над показателями производительности, которые вы видите, так как файл / DB / Memcache / Redis все будут обрабатывать с удовольствием трафик, не нарушая пот при правильном использовании.

Это оставляет другие факторы, такие как масштабируемость, надежность и безопасность.

Прежде всего, я бы хотел сказать, что все, что подрывает ваше файловое хранилище, вероятно, подорвет что-либо еще, так как злоумышленник может просто изменить код вашего приложения или, по крайней мере, обнаружить ключи и протоколы / учетные данные для доступа к хранилищу, даже если они имеют только чтение. доступ. Файловое хранилище будет хорошо работать для сайта с небольшим объемом, его легко настроить и легко обдумать. Если вы говорите, что попали на диск, чтение из БД также попадет на диск, и, если БД сможет его кешировать, ваша ОС, скорее всего, также кеширует файл сеанса. Кроме того, он прочитан одним файлом, и ваша файловая система прекрасно справится с задачей, если вы уже знаете его имя. Если вы используете PHP, знаете ли вы, сколько операций чтения файлов требуется системе для обслуживания вашего приложения? Недостатком является то, что вы можете

Memcache является относительно быстрым, и если вы рассматриваете классовые решения Memcache более широко (Redis и т. Д.), Есть такие, которые даже обещают постоянство при чтении в памяти для скорости, так что вы получите максимум от обоих миров. Они также относительно просты для рассуждения, и природа сеансов ключ-значение - это именно то, для чего они были предназначены. Знаете ли вы, сколько вам придется потратить на сессию, чтобы заполнить одну из них? В любом случае, все ваши варианты заставят вас пойти на компромисс, если вы достигнете их возможностей. Диски заполняются файлами (здесь указан коэффициент количества и размера), емкости кэш-памяти заполняются, а базы данных имеют ограниченное количество строк и те же ограничения емкости диска, что и файловый подход. Кроме того, эти системы распространяются только в том случае, если вы запускаете их распределенным способом. Большинство работает просто отлично с настройкой одного сервера. Если вы распространяете их, то, вероятно, у вас уже есть распределенные веб-серверы / серверы баз данных и т. Д., Поэтому проблемы с распределенной системой, безусловно, не будут отображаться при выборе хранилища сеансов. Тем не менее, когда вам требуется 10-кратный трафик / емкость и т. Д., Добиться этого гораздо естественнее, чем схемы хранения файлов. Некоторые хранилища ключей / значений также позволят вам сравнительно легко провести простой анализ данных сеанса, но большинство из них не приблизят вас к возможностям SQL.

Я не уверен, почему вы предлагаете, чтобы база данных была более надежной, чем другие варианты, но я понимаю привлекательность базы данных, поскольку ваше PHP-приложение, вероятно, уже использует ее. Это означает, что вы не добавляете другую зависимость от сервера и, вероятно, можете повторно использовать то же соединение, которое используете для извлечения данных сеанса, чтобы получить пользовательские данные, поэтому вам не нужно устанавливать одно для данных, другое для Memcache и т. Д. Если вы индексируете Что касается таблицы, то она также будет работать достаточно быстро и предоставляет довольно простую семантику, с которой вы уже знакомы, для того, чтобы пожинать старые сеансы или даже анализировать данные сеансов (я не уверен, почему вы захотите, а если нет, то, вероятно, это не так). это не имеет большого значения). Масштабирование до масштабных масштабов не так тривиально, как с чем-то вроде Redis,

Я думаю, что этот выбор не так важен в начале. У каждого подхода есть проблемы, преимущества и вещи, о которых вы должны подумать. Вообще говоря, вы, вероятно, можете обойтись, просто используя значения по умолчанию PHP / любой другой фреймворк, который вы используете, или даже просто самое простое в использовании. Если впоследствии выбор окажется неудачным, ваша аналитика производительности скажет вам, и вы будете вооружены данными, которые вам необходимы, чтобы сделать правильный выбор, учитывая конкретный характер получаемого вами трафика. Вначале все, что вы можете разумно иметь, это общие предположения.

jeteon
источник
0

Это зависит от ваших потребностей.

Есть некоторые различия между файлами и хранилищем базы данных. Смотрите этот вопрос .

Тем не менее, вы можете делать то, что сделано в Rails 3 по умолчанию, и использовать только зашифрованные куки для вашего сеанса. Таким образом, вы шифруете все значения таким образом, чтобы только вы могли расшифровать его позже (например, закрытые / открытые ключи), и вы позволяете клиенту сохранять состояние за вас.

С одной стороны, он ограничивает вас 4 КБ, чего обычно достаточно (поскольку вы обычно хотите хранить идентификаторы, а не целые объекты), но вы получаете действительно хорошее преимущество - вам не нужно беспокоиться об очистке сессии. Вы оставляете это до клиента, где это на самом деле должно быть.

Ям Маркович
источник
2
Если вы не выделили свои статические ресурсы за пределы пути к файлам cookie, файлы cookie являются фиксированным налогом, который вы должны платить при каждом запросе.
Джоери Себрехтс
jQuery и Bootstrap вместе составляют около 150 КБ, и это без других библиотек. Максимальный размер файла cookie составляет 4 КБ, и обычно ниже 1 КБ. Если ОП не задает вопрос об экстремальных обстоятельствах - кого волнует такого рода налогообложение?
Ям Маркович
@YamMarcovic есть несколько проблем: 1) cookie-файлы тоже отправляются на сервер (пользователи обычно быстрее загружают, чем загружают) 2) обычно страницы имеют 100 запросов на статические файлы (изображения, js, css), поэтому они могут попасть в 100 КБ при каждом запросе идет вверх
Миро Свртан
@MiroSvrtan Если вы заставляете своих пользователей отправлять сотни запросов на страницу (где это когда-либо происходило?), Оптимизация явно не проблема для вас.
Ям Маркович
У меня был клиент, чей сайт отправлял ~ 170 HTTP-запросов на загрузку главной страницы, прежде чем посоветоваться со мной по оптимизации скорости, так что, поверьте, поверьте. Кстати, закрытые / открытые ключи представляют собой концепцию асимметричной криптографии, которая, как правило, не применяется в этом сценарии, где ее эквивалент симметричному шифру только сложнее реализовать. Кроме того, большинство реализаций хранилища сеансов полагаются на некоторые cookie-файлы, управляемые клиентом, поэтому преимущества, описанные в последнем абзаце ответа, относятся ко всем из них.
Jeteon
0

В моей конкретной ситуации я могу вам сказать, что сеансы в базе данных - это причина номер один для зависания нашего сервера с хорошим запасом. наша таблица сессий повреждается достаточно часто, поэтому мы ее упреждаем.

memcache звучит привлекательно, но у нас слишком много процессов, которые очищают весь memcache, поэтому пользовательские сессии будут отключаться слишком часто. и старые сеансы будут очищены, когда память заполнится ... так что больше не будет постоянных входов в систему.

Мы скоро попробуем стандартные файловые сессии.

Если вас беспокоит безопасность данных вашего сеанса, вам не следует помещать эти данные в сеанс - и не доверять сеансу - проверять пользователя при каждом запросе.

changokun
источник
0

Вы можете попытаться сохранить ваш сеанс на Redis . Redis быстрый, как Memcached, но также имеет несколько вариантов сохранения данных. Кроме того, поддерживаются различные клиенты PHP.

Кроме того, вы можете попробовать сторонние сервисы, такие как Memcached Cloud, которые имеют встроенные функции репликации и хранилища.

Раскрытие, я соучредитель и технический директор Garantia Data.

Ифтак Шулман
источник
2
Спасибо за раскрытие! Убедитесь, что вы участвуете на этом сайте, помимо публикаций, где вы можете упомянуть свои собственные продукты, хотя мы хотим, чтобы вы, как личность, внесли свой вклад, а не как ваша компания.
Мартин Питерс