Трудно ли масштабировать сессии PHP в распределенной системе?

Question

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

Answer 1

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

http://www.php.net/manual/en/function.session-set-save-handler.php

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

вот как это сделать в Redis - мы используем это сейчас: http://redis4you.com/articles.php?id=001&name=Redis+as+session+handler+in+PHP

Answer 5

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

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