есть определенные темы по этому поводу, но у меня есть еще один вопрос.
Мы собираемся масштабировать веб-сайт на работе, чтобы иметь более одного сервера. И мы необходимость для разделения сеансов между серверами.
Мы изучаем разные решения, одно в memcached и использовать Memcached в качестве обработчика сеанса в PHP. Вероятно, это сработает.
Идея заключалась бы в том, чтобы запустить memcached на каждой машине и позволить всем веб-серверам обращаться ко всем остальным серверам memcached, а затем у нас будут общие сеансы между машинами, ура. (у нас пока нет ресурсов для установки с липкими сессиями, это более поздний проект. Нам нужно, чтобы это работало, и нам нужно, чтобы это работало сейчас. И мы будем балансировать нагрузку с DNS для начала)
Но тогда ... Если я хочу остановить один сервер, скажем, для обслуживания, или сервер выйдет из строя, или по любой другой причине. Я не хочу, чтобы пользователи просто теряли свои сеансы и начинали с самого начала ... Вот почему нам нужна какая-то репликация, которую Memcached не поддерживает.
Затем я нашел http://repcached.lab.klab.org/ - который имеет репликацию memcached с несколькими мастерами, что здорово, и это то, что я хочу. Но работает ли он с> 2 машинами? Скажите 3, 5, 10? Для будущего масштабирования.
Я также заглянул в Redishttp://redis.io/ - что тоже кажется отличным, но немного более "шатким" с поддержкой php-session-handler и отсутствием multi-master-репликации.
Дело в том, что мне нравится использовать memcached, но я хочу иметь возможность отключать одно из двух устройств без потери половины сеансов. Какие-либо предложения?
Возможно, вы захотите взглянуть на couchdb, который реализует реплицированное хранилище ключей с API memcache. Он также обрабатывает переполнение хранилища памяти более изящно, чем большинство реализаций memcache (вероятный результат при переключении). Должен признать, что я не знаком с деталями того, как он реализует репликацию.
Все реализации `` липких '' сеансов, которые я видел, привязывают запрос к явному устройству, что не способствует хорошей отработке отказа, а с PHP привязка сеанса актуальна только для подложки хранения (в отличие от Java, где обычно требуется быть на логическом уровне). Поэтому использование липких сеансов на уровне HTTP не имеет значения.
Конечно, использование асинхронной репликации MySQL в подложке нетривиально из-за задержки репликации и однопоточных операций записи - я использую брокер соединений в PHP (который реализует предпочтения и блоки во время аварийного переключения), чтобы решить эту проблему. Хотя MySQL не является самым эффективным решением для обработки сеансов, если ваши приложения уже полагаются на реляционную базу данных с высокой доступностью, тогда имеет смысл использовать ее для хранения сеансов. Для MySQL существуют реализации репликации с несколькими мастерами - например, Percona.
MongoDB также использует асинхронную репликацию, но без однопоточной зависимости MySQL.
Вам придется потратить некоторое время на размышления о том, как ограждать узлы. Захват виртуального адреса (если реализован правильно) должен сделать операцию прозрачной, но IME может быть сложно выполнить правильно, и ему необходимо захватить адрес arp, а также IP-адрес, чтобы избежать больших пауз во время переключения при отказе.
Скажите 3, 5, 10? Для будущего масштабирования
Если вы планируете масштабирование до такой степени, то вам, вероятно, следует подумать о нескольких центрах обработки данных, что подразумевает метод синхронизации, который может справиться с низкой пропускной способностью / более высокой задержкой, то есть не с общей файловой системой.
Я бы рекомендовал обработчик сеанса базы данных вместо memcached. Вы, вероятно, все равно используете базу данных, и если ваша база данных не работает, значит, ваш сайт тоже не работает, поэтому вы не добавляете новые режимы сбоя.
Memcached не поддерживает аварийное переключение. Аннулирование кеша в таких средах с несколькими главными устройствами в любой системе является либо медленным и сложным (синхронным), либо ненадежным (асинхронным). Таким образом, у вас могут возникнуть ситуации, когда вы устанавливаете некоторую переменную сеанса на одном сервере, а следующий запрос отправляется на другой сервер, у которого есть старое значение этой переменной.