Мы переходим от настройки одного веб-сервера к настройке с двумя веб-серверами, и мне нужно начать совместное использование сеансов PHP между двумя машинами с балансировкой нагрузки. Мы уже имеем memcached установлены (и начал), и поэтому я был приятно удивлен, что смог выполнить сеанс обмена между новыми серверами, изменив только 3 строки в php.ini файл ( session.save_handler и session.save_path):
Заменил:
session.save_handler = files
с участием:
session.save_handler = memcache
Затем на главном веб-сервере я установил session.save_path указать на localhost:
session.save_path="tcp://localhost:11211"
и на подчиненном веб-сервере я установил session.save_path указать на мастера:
session.save_path="tcp://192.168.0.1:11211"
Работа сделана, протестировал, работает. Но...
Очевидно, что использование memcache означает, что сеансы находятся в ОЗУ и будут потеряны, если машина будет перезагружена или демон memcache выйдет из строя - меня это немного беспокоит, но меня немного больше беспокоит сетевой трафик между двумя веб-серверами (тем более, что мы увеличиваем масштаб), потому что всякий раз, когда кто-то балансирует нагрузку на подчиненный веб-сервер, их сеансы будут загружаться по сети с главного веб-сервера. Мне было интересно, могу ли я определить два save_paths поэтому машины перед использованием сети просматривают свои собственные хранилища сеансов. Например:
Мастер:
session.save_path="tcp://localhost:11211, tcp://192.168.0.2:11211"
Раб:
session.save_path="tcp://localhost:11211, tcp://192.168.0.1:11211"
Будет ли это успешно разделять сеансы между серверами И повышать производительность? то есть экономить сетевой трафик в 50% случаев. Или этот метод предназначен только для отработки отказа (например, когда один демон кэша памяти недоступен)?
Заметка: Я на самом деле не спрашиваю конкретно о репликации кэша памяти - больше о том, может ли клиент PHP кэша памяти достигать пика внутри каждого демона кэша памяти в пуле, возвращать сеанс, если он его находит, и создавать новый сеанс, только если он не находит его в все магазины. Пока я пишу это, я думаю, что прошу многого от PHP, лол ...
Предполагать: без липких сессий, циклической балансировки нагрузки, серверов LAMP.
Отказ от ответственности: вы были бы безумны, если бы послушали меня, не выполнив тонну тестирования И не получив второе мнение от кого-то квалифицированного - Я новичок в этой игре.
Идея повышения эффективности, предложенная в этом вопросе, не сработает. Основная ошибка, которую я совершил, заключалась в том, что я подумал, что порядок, в котором хранилища memcached определены в пуле, диктует какой-то приоритет. Это не вариант. Когда вы определяете пул запоминаемых демонов (например, используя session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211") вы не можете знать, какой магазин будет использоваться. Данные распределяются равномерно, что означает, что элемент может быть сохранен в первом или последнем (или может быть и то, и другое, если клиент memcache настроен на репликацию - обратите внимание, что это клиент, который обрабатывает репликацию, сервер memcached делает не делай сам). В любом случае это будет означать, что использование localhost в качестве первого в пуле не улучшит производительность - вероятность попадания в любой из хранилищ составляет 50%.
Проведя небольшое тестирование и исследование, я пришел к выводу, что вы МОЖЕТЕ обмениваться сеансами между серверами, используя кэш памяти, НО вы, вероятно, не хотите этого - он не кажется популярным, потому что он не масштабируется так же хорошо, как использование общего база данных на нем не такая надежная. Буду признателен за обратную связь по этому поводу, чтобы я мог узнать больше ...
Игнорируйте следующее, если у вас нет приложения PHP:
Убедитесь, что вы ответили да к "Включить поддержку обработчика сеанса memcache?"когда вы установили клиент PHP memcache и добавили следующее в свой /etc/php.d/memcache.ini файл:
session.save_handler = memcache
На веб-сервере 1 (IP: 192.168.0.1):
session.save_path="tcp://192.168.0.1:11211"
На веб-сервере 2 (IP: 192.168.0.2):
session.save_path="tcp://192.168.0.1:11211"
Добавьте следующее в свой /etc/php.d/memcache.ini файл:
memcache.hash_strategy = consistent
memcache.allow_failover = 1
На веб-сервере 1 (IP: 192.168.0.1):
session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"
На веб-сервере 2 (IP: 192.168.0.2):
session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"
Ноты:
session.save_path на всех серверах. То же, что и совет 2, за исключением того, что вам нужно добавить следующее в свой /etc/php.d/memcache.ini файл:
memcache.session_redundancy=2
Ноты:
get's повторяются на зеркалах. Это будет означать, что пользователи не теряют свою сессию в случае сбоя одного демона memcache.memcache.session_redundancy предназначен для резервирования сеанса, но есть также memcache.redundancy ini, который может использоваться кодом вашего PHP-приложения, если вы хотите, чтобы он имел другой уровень избыточности.Re: Совет 3 выше (для всех, кто сталкивался с этим через Google), кажется, что по крайней мере в настоящее время для того, чтобы это работало, вы должны использовать memcache.session_redundancy = N+1 для N серверов в вашем пуле, по крайней мере, это минимальное допустимое пороговое значение. (Протестировано с помощью php 5.3.3 на стабильной версии debian, pecl memcache 3.0.6, два сервера memcached. session_redundancy=2 выйдет из строя, как только я отключу первый сервер в save_path, session_redundancy=3 работает отлично.)
Кажется, это отражено в этих отчетах об ошибках:
Наряду с показанными выше настройками php.ini убедитесь, что установлены следующие параметры:
memcache.allow_failover = 1
memcache.hash_strategy = 'consistent'
Тогда вы получите полное аварийное переключение и резервирование на стороне клиента. Предостережение с этим подходом заключается в том, что если memcached не работает на локальном хосте, всегда будет промах при чтении до того, как клиент php memcache попытается сделать следующий сервер в пуле, указанном в session.save_path
Просто имейте в виду, что это влияет на глобальные настройки клиента php memcache, запущенного на вашем веб-сервере.
memcached так не работает (поправьте меня, если я ошибаюсь!)
Если вы хотите, чтобы ваше приложение имело избыточное хранилище сеансов, вам нужно создать что-то, что изменяет / добавляет / удаляет записи в обоих экземплярах memcached. memcached не справляется с этим, единственное, что он предоставляет, - это хранилище хэшей ключей. Так что никакой репликации, синхронизации, ничего, нада.
Надеюсь, я не ошибаюсь в этом вопросе, но это то, что я знаю о memcached, прошло несколько лет с тех пор, как я коснулся его.
memcached не реплицируется из коробки, но перекэшированный (исправленный memcached) делает. Однако, если вы уже используете mysql, то почему бы просто не использовать его функции репликации с репликацией мастер-мастер и получить преимущества полной репликации данных.
С.