Сессии PHP в кластере выравнивания нагрузки - как?
Ваш сценарий должен:
- знать, какие системные шрифты доступны и где находятся файлы шрифтов (например, C: \ Windows \ Fonts)
- проверять эти файлы. для их содержания. Я полагаю, что их проверка может быть выполнена техническим способом, распутывая форматы файлов. Но вы также можете имитировать визуальное использование, вычисляя ограничивающую рамку или имитируя использование шрифта для символов эмодзи.
Если вы в PHP , вы можете вычислить ограничивающую рамку шрифтов TTF, которые известны для эмодзи, и посмотреть, является ли значение тем, что следует ожидать от шрифта, который его поддерживает.
Вы также можете смоделировать использование шрифта, нарисовав черное изображение в памяти белым шрифтом, используя GD , и рассчитать (среднее) количество белых пикселей, чтобы увидеть, соответствует ли оно ожидаемому порог.
Вы также попросили проверить, отобразит ли их текущее приложение терминала. Для этого вам нужно иметь возможность проверить конфигурацию, которая не является тривиальной, так как вам нужно иметь возможность различать во всех терминальных приложениях. Практическим решением было бы отобразить некоторые эмодзи с текущим шрифтом, а просто спросить пользователя , отображается ли он. В конце концов, вам все равно нужно полагаться на пользователя, если терминальное приложение должно поддерживать Emoji?
6 ответов
Вы можете настроить PHP для обработки сеансов в базе данных, чтобы все ваши серверы использовали одну и ту же информацию о сеансе, поскольку все серверы используют для этого одну и ту же базу данных.
Хорошее руководство для этого может быть найдено здесь .
Вы не упомянули, какую технологию вы используете для балансировки нагрузки (программное обеспечение, оборудование и т. Д.); но в любом случае решение вашей проблемы - использовать «липкие сеансы» в балансировщике нагрузки.
Вкратце, это означает, что когда приходит первый запрос от «нового» посетителя, ему назначается конкретный сервер из кластера: все будущие запросы на время существования их сеанса затем направляются на этот сервер. На практике это означает, что приложения, написанные для работы на одном сервере, можно масштабировать до сбалансированной среды с нулевым / небольшим количеством изменений кода.
Если вы используете аппаратный балансировщик, такой как устройство Radware, то липкие сеансы настраивается как часть настройки кластера. Аппаратные устройства обычно предоставляют более точный контроль: например, к какому серверу назначен новый пользователь (они могут проверять состояние работоспособности и т. д. и выбирать наиболее работоспособный / наименее загруженный сервер), а также больший контроль над тем, что происходит, когда сервер выходит из строя и выходит из кластера. Недостатком аппаратных балансировщиков является их стоимость, но они того стоят, imho.
Что касается программных балансировщиков, все зависит от того, что вы используете. Для Apache есть свойство stickysession на mod_proxy - и множество статей через Google, чтобы заставить это работать с сеансом php ( например )
Изменить: все сводится к тому, что вы используете. Для Apache есть свойство stickysession на mod_proxy - и множество статей через Google, чтобы заставить это работать с сеансом php ( например )
Изменить: все сводится к тому, что вы используете. Для Apache есть свойство stickysession на mod_proxy - и множество статей через Google, чтобы заставить это работать с сеансом php ( например )
Изменить: Судя по другим комментариям, опубликованным после исходного вопроса, похоже, что ваша «балансировка» осуществляется через Round Robin DNS, поэтому приведенное выше, вероятно, не применимо. Я воздержусь от дальнейших комментариев и разжигания пламени против циклических DNS.
Проще всего настроить балансировщик нагрузки так, чтобы он всегда отправлял один и тот же сеанс на один и тот же сервер.
Если вы все еще хотите использовать session_set_save_handler , возможно, возьмите посмотрите на auto_prepend.
Когда у нас возникла такая ситуация, мы реализовали некоторый код, который живет в общем заголовке.
По сути, для каждой страницы мы проверяем, знаем ли мы идентификатор сеанса. Если мы этого не сделаем, мы проверим, находимся ли мы в ситуации, которую вы описываете, проверяя, сохранили ли мы данные сеанса в БД. В противном случае мы просто запускаем новый сеанс.
Очевидно, это требует, чтобы все соответствующие данные были скопированы в БД, но если вы инкапсулируете данные сеанса в отдельный класс, все работает нормально.
вы также можете попробовать использовать кэш памяти в качестве обработчика сеанса
Если вы используете сеансы php, вы можете совместно использовать NFS каталог / tmp, где, я думаю, хранятся сеансы, между всеми серверами в кластере. Таким образом, вам не нужна база данных.
Отредактировано: вы также можете использовать внешний сервис, такой как memcachedb (постоянный и быстрый), и сохранить информацию о сеансе в индексе memcachedb и идентифицировать его с помощью хеш-кода содержимого или даже сеанса ID