#php #mysql #session #memcached
#php #mysql #сессия #memcached
Вопрос:
Для веб-сайта с высоким трафиком мы планируем расширить использование 2 веб-серверов в настройке HA.
Одна из проблем, которую нам нужно будет решить, — это управление сеансами PHP.
Очевидный ответ — перенести обработку сеанса в БД, что несложно, а пример кода широко доступен в Интернете.
С другой стороны, мы знаем о преимуществах memcached, но как только узел memcached выходит из строя, пользователи на этом узле теряют сеанс.
Итак, мы думаем о реализации настройки, при которой сеансы обрабатываются в memcached по умолчанию, но также записываются в БД. Когда мы получаем ошибку memcached, мы также пытаемся извлечь ее из базы данных.
Имеет ли смысл вышесказанное и известны ли вам какие-либо примеры реализации?
заранее спасибо
Комментарии:
1. почему просто не использовать PHP cloud? это сэкономило бы вам 60% работы
2. Я предлагаю вам прочитать этот вопрос из serverfault.com .
Ответ №1:
Я отсылаю вас к часто цитируемому объяснению Dormando о том, как хранить сеансы в MySQL с помощью кэширования memcached. Оригинальный пост в LiveJournal более многословен, но более подробно объясняет, почему хранение сеансов только в memcached — плохая идея.
Короче говоря:
- Сначала прочитайте данные сеанса из memcached, посмотрите в MySQL на отсутствие кэша.
- Записывайте данные сеанса в memcached при каждом обновлении.
- Запись в MySQL выполняется только в том случае, если данные кэша не были синхронизированы в течение 120 секунд или около того.
- Периодически запускайте скрипт, который проверяет MySQL на наличие истекших сеансов. Для каждого истекшего сеанса обновляйте из memcached и проверяйте только те, срок действия которых действительно истек.
Комментарии:
1. Создавать дополнительные операции ввода-вывода и запросы к БД для обработки сеансов — глупая идея. У меня есть опыт использования Memcache и APC для сессий, а также MySQL. Без сеансов MySQL работает в 10-20 раз быстрее.
2. У меня есть опыт разработки систем, для которых требуется высокая надежность, а из-за пропущенных сессий на вас кричат. Использование энергозависимого кэша в качестве единственного постоянного хранилища для любых данных, которые вас интересуют, вызывает проблемы.
3. @OZ_, это больше о восприятии нестабильности. Пользователям не нравится, когда они выходят из системы в середине сеанса, потому что узел memcached отключился. Зачем вообще беспокоиться о настройке кластера HA, если вы просто собираетесь хранить сеансы в memcached и надеяться на лучшее? Это не «в 10-20 раз быстрее», чем правильно разработанная настройка memcached MySQL, а MySQL store обеспечивает лучшее из обоих миров — скорость и надежность.
4. @OZ_, вопрос был о конфигурации высокой доступности. Я предполагаю, что это означает, что переход узла в автономный режим не должен оказывать видимого влияния на систему. Даже когда ни один узел memcached не переходит в автономный режим, вы все равно можете потерять данные сеанса, если кэш используется чрезмерно. Не имеет большого значения, является ли постоянное хранилище MySQL или Redis; разработчики memcached и другие разработчики HA рекомендуют использовать memcached только для кэширования, а не для хранения.
5. Возможно, вам следует попытаться немного лучше понять контекст и бизнес-требования. Один только Memcache не подходит для наших сеансов. Мы просто не хотим вводить отдельные точки отказа для наших переменных сеанса! Memcache (как кэш) с постоянным хранилищем на серверной части хорошо подходит для наших требований, и у нас уже есть инфраструктура, запущенная. Кажется, Redis с файлами только для добавления может достичь чего-то подобного.
Ответ №2:
Сеансы — это временная вещь, не о чем беспокоиться, если раз в месяц memcache-сервер будет давать сбой и обрезать сеансы. Я уверен, что вы можете использовать только memcache для сессий, без репликации в DB.
Но если вы все еще хотите выгружать сеансы на диск, в качестве существующего решения вы можете использовать Redis:
Redis работает с набором данных в памяти. В зависимости от вашего варианта использования, вы можете сохранить его либо путем сброса набора данных на диск
…
Redis также поддерживает простую в настройке репликацию master-slave с очень быстрой неблокирующей первой синхронизацией, автоматическим переподключением при разделении сети и так далее.