Каков наилучший способ обмена информацией о сеансах между 4 центрами обработки данных и 40 серверами? - PullRequest
3 голосов
/ 21 июля 2010

В настоящее время наш DNS направляет пользователя в правильный центр обработки данных, а затем у нас возникает ситуация циклического перебора для серверов. В настоящее время мы храним информацию о сеансе в куки, но она становится слишком большой, поэтому мы хотим переместить ее из браузера в базу данных. Я обеспокоен тем, что если мы создадим среднюю коробку, в которую они все попадут, это повлияет на время отклика. Невозможно хранить информацию о сеансе на всех машинах, потому что мы говорим о 200M + уникальных сеансах в месяц. Есть предложения, мысли?

Ответы [ 2 ]

4 голосов
/ 22 июля 2010

Давайте разберемся с ролью куки на основе браузера

  • Cookies хранятся в браузере профиль.
  • Один и тот же пользователь вошел в систему с разных компьютеров или браузеров считаются разными пользователями.
  • Государственные куки смешиваются с пользовательскими куки

Разделить куки.

  • Долгосрочные государственные куки, например, текущий запоминаемый идентификатор пользователя.
  • куки-файлы состояния сеанса
  • пользовательские куки

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

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

Это означает, что вы должны внедрить систему распределенных баз данных. У вас есть главный сервер БД. Допустим, у вас есть 20 веб-серверов, каждый из которых имеет собственную базу данных.

Храните только часто изменяемые файлы cookie в локальной базе данных и оставляйте редко меняющиеся файлы cookie на главном сервере.

Каждый раз, когда файл cookie обновляется на локальном БД, обновленный флаг ставится в очередь для обновления на мастер. Запись cookie в мастер-файле не обновляется, она помечается как устаревшая с номером местоположения, в котором находятся свежие данные. Таким образом, если этот идентификатор пользователя каким-либо образом активируется за 3000 миль одновременно, этот сеанс обнаружит устаревшие записи и инициирует запрос на копирование из этих записей из свежего местоположения в его собственную локальную базу данных и в главную базу данных и записи, больше не помеченные как несвежий на мастер дб.

Затем вы планируете регулярную синхронизацию наиболее часто используемых файлов cookie. Частота синхронизации может быть ночной или зависит от результата характеристики изменения cookie.

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

Вы выполняете простую статистическую характеристику для каждого файла cookie, идентификатора пользователя и частоты изменений. Затем вы скользите по своим предпочтениям, решая, какой файл cookie будет передан во все локальные базы данных, а какой останется на главном. Решение балансирует между размером блока cookie в локальной базе данных и частотой синхронизации базы данных, которую вы готовы разрешить. Это означает, что не у каждого пользователя одинаковый набор файлов cookie. Конечно, ваши программисты должны написать подпрограммы для автоматизации регулярной повторной характеристики. Вместо того чтобы использовать пользователя, вы можете уменьшить нагрузку по обработке распространения файлов cookie, группируя своих пользователей с помощью кластерного анализа. Может быть, группировка пользователей для вашего сайта настолько очевидна, что вам не нужно выполнять кластерный анализ.

Вы можете быть удивлены, обнаружив, что большинство файлов cookie могут попадать в корзину обновлений, которая дольше, чем еженедельно.Или в худшем случае, ежедневное обновление.и наихудший случай, который вы должны принять - это ежечасное обновление для полей cookie, которые не помещаются в локальные базы данных.Вы хотите увеличить вероятность того, что доступ к cookie-файлам будет получен на локальной базе данных, а не будет извлечен из основной базы данных.Поэтому, когда пользователь решает щелкнуть «предпочтения», которые редко изменяются, вы вытягиваете записи предпочтений из мастера, одновременно отвлекая пользователя некоторыми изысками, такими как «Вы рассматривали предварительный просмотр нашего нового сервиса?», «Вы хотели бы ответитьнаше исследование юзабилити? "," новая выговор Гибсона, прокомментируете ли вы? "и т. д. до тех пор, пока файлы cookie" предпочтений "не будут скопированы.

Характеристика файлов cookie может быть выполнена для каждого идентификатора пользователя или группы пользователей.решите, какое поле cookie передавать в локальную базу данных.

Проще описать каждый идентификатор пользователя, поскольку он едва ли требует каких-либо навыков статистического анализа со стороны программиста.Недостатком является то, что веб-сервер должен будет принимать решения для каждого из 200 миллионов пользователей.Таблица файлов cookie базы данных будет

Cookie[id, param, value, expectedMutationInterval].

Ваш веб-сервер будет решать для каждого пользователя, какой файл cookie регулярно отправлять к пороговому времени.

SELECT param, value
WHERE expectedMutationInterval < $thresholdTime
  AND id = UserId

Вам необходимо регулярно проводить повторную характеристику файлов cookie дляОбновление ОжидаемыйMutInterval для пользователя на файл cookie.Простой запрос SQL сможет выполнить обновление Ожидаемый МутацияИнтервал.Более сложный анализ мог бы быть выполнен, чтобы произвести значение ожидаемыйMutationInterval.

Если каждое изменение поля cookie регистрируется по времени, userid и ipaddr, тогда ваша таблица журнала cookie будет иметь вид

CookieLog[id, time, ipaddr, param, value].

, что поможет вашей программе автоматической рехарактеризации определить, какие поля отправлять в зависимости отdayofweek / месяц / сезон и местоположение / регион / ipaddr.

Затем, после удаления файлов cookie с информацией о пользователе из браузера, если вы по-прежнему обнаруживаете, что ваши файлы cookie Sessison переполняются, вы теперь решаете, какие файлы cookie сеанса отправлять в браузер, а какиеостается на локальном сервере.Вы используете ту же самую методику master-local db analysis, но теперь она используется для выбора между локальной базой данных и отправкой в ​​браузер.Вы оставляете свои файлы cookie сеанса с наименьшим количеством посещений на локальном сервере, либо в качестве атрибутов сеанса, либо в базе данных в памяти.Поэтому, когда клиент обнаруживает, что файл cookie отсутствует, он отправляет запрос на сервер для файла cookie, жертвуя при этом не так часто используемым в последнее время / часто используемым пространством файлов cookie в браузере для размещения этого свежего файла cookie.

Поскольку этоСеансовые куки, их нужно распространять в другие места, потому что если тот же ИД пользователя зарегистрирован на 3000 миль, у него должен быть свой собственный набор сеансовых куки.

Характеристика браузерных куки - это ирония, потому что для приложений AJAXклиент получает доступ к файлам cookie, не сообщая об этом серверу.Уведомление сервера может помешать цели размещения файлов cookie в браузере.Таким образом, вам придется выбирать время простоя, чтобы отправлять доступ к файлам cookie на сервер для регистрации.

Такой уровень детализации хорош для файлов cookie с короткой длиной (значение параметра + имя параметра), будь тоЭто cookie, основанные на сеансах или пользователях.

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

Как вы облегчаете квантование файлов cookie на основе браузера?Используя GWT в качестве примера, используйте класс Dictionary или Map.

Например, cookie "% 1" = "^ $ Kdm3i" может переводиться в LastConnectedFriend=MohammadAli@jinnah.

.

Вам не нужно выполнять характеристику, например, зачем хранить ваш файл cookie как «LastConnectedFriend», когда вы можете сопоставить его с «% 1»?Когда пользователь входит в систему, почему бы не сопоставить наиболее часто посещаемых друзей и т. Д. И разместить эту карту на странице запуска GWT / AJAX?Таким образом, вы могли бы сократить длину файлов cookie вашего сеанса.

Итак, ваша компания ищет программиста-статистика?Отказ от ответственности заключается в том, что это написано не по назначению и может потребовать некоторой фактической корректировки.

4 голосов
/ 22 июля 2010

Задание для memcached или, если вы хотите сохранить данные сеанса на диск, memcacheddb

Memached - бесплатный и открытый исходный код, высокийвысокопроизводительная система кеширования объектов распределенной памяти, универсальная по своей природе, но предназначенная для использования для ускорения динамических веб-приложений за счет снижения нагрузки на базу данных.

Memcached - это хранилище значений ключей в памяти для небольших фрагментов произвольных данных(строки, объекты) из результатов вызовов базы данных, вызовов API или рендеринга страницы.

Memcached прост, но мощен.Его простая конструкция обеспечивает быстрое развертывание, простоту разработки и решает многие проблемы, связанные с большими кэшами данных.Его API доступен для большинства популярных языков.

...