Сложно ли масштабировать сеансы PHP в распределенной системе?

Question

На работе мы почти все делаем на Java и perl, но я хотел создать функцию с использованием PHP и сессий.Некоторые пользователи подумали, что пытаться проводить сеансы PHP в нашей системе - плохая идея, потому что он распространен на многих серверах.В чем может заключаться конкретная проблема?

Answer 1

Ответ на ваш конкретный вопрос, в чем заключается проблема, заключается в том, что по умолчанию PHP хранит свои сеансы в файлах в файловой системе. Для одного веб-сервера, обслуживающего запросы, это не проблема, потому что данные вашего сеанса всегда будут доступны. Но что, если у вас есть два веб-сервера с балансировкой нагрузки, обслуживающих запросы?

Представьте, что вы обращаетесь к первому веб-серверу с запросом, который создает файл сеанса в его файловой системе. Затем ваш следующий запрос попадает на второй веб-сервер. Второй веб-сервер, конечно, не увидит файл сессии. Для пользователя вы можете войти на веб-сайт, а затем внезапно выйти из него.

Это не проблема, специфичная для PHP, и она очень распространена. Решение состоит в том, чтобы хранить данные сеанса в некоторой общей области. Наиболее распространенным способом для этого является хранение данных сеанса либо в базе данных, доступной для всех веб-серверов, либо на каком-либо сервере кеша общей памяти, например memcached.

Answer 2

Вы также можете использовать пользовательский обработчик сохранения сеанса:

http://www.php.net/ ручной / EN / function.session-зор-копи-handler.php

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

Также Msession, предложенный @Eran Galperin, выглядит очень интересной альтернативой тому, о котором я упоминал ранее.

Answer 3

Сохранение сеансов на нескольких серверах (также называемое кластеризацией сеансов) является распространенной проблемой для масштабирования веб-приложений и не относится к PHP. PHP предлагает несколько решений для решения этой проблемы, например Zend Platform (коммерческий сервер приложений) и Msession (расширение).

Answer 4

Довольно расплывчатый вопрос, но я бы сказал, что проблема серьезнее, чем указано в ответах.Конечно, вы можете переопределить способ загрузки и сохранения файлов cookie, но это тоже сопряжено с определенными затратами.Например, вам нужно будет рассмотреть следующие сценарии / вопросы:

• Если вы размещаете файлы cookie на другом хостинге, как это повлияет на скорость передачи ваших файлов cookie?Это, очевидно, зависит от того, сколько операций записи / чтения вы производите.
• Вы делаете это для увеличения скорости или для отработки отказа?Ответ, безусловно, приведет к различным решениям:
  • В случае, если вы делаете это для отработки отказа, как вы будете реагировать, если ваши веб-серверы не смогут получить доступ к вашему хранилищу сеансов из-за отключения сетевого соединения?Что делать, если ваше хранилище сеансов отключится?Вам придется решить эту проблему, используя какую-то репликацию master-master, возможно, запустив это распределенное хранилище сеансов на том же компьютере, что и веб-сервер, для обеспечения более высокой доступности (если все сеансы могут поместиться в памяти).Взгляните на Риак или аналогично для репликации master-master.
  • В случае, если вы просто делаете это для скорости, я бы использовал apache, nginx или (самый быстрый) haproxy, чтобы просто выполнять балансировку нагрузки на основе IP-адреса клиента.Таким образом, вам не придется беспокоиться о настройке распределенного хранилища сеансов.Конечно, если один из ваших PHP-экземпляров выйдет из строя, ваши пользователи потеряют свои файлы cookie, но, возможно, это не проблема.Это зависит от вас.

Answer 5

проще всего - memcached или redis.

вот как это сделать в Redis - мы используем это сейчас: http://redis4you.com/articles.php ? ID = 001 & амп; имя = Redis + а + сессии + обработчик + в + PHP