Давайте понимать роль куков браузера на основе
- Куков хранятся в браузер профиля.
- Тот же пользователь, вошедший в систему с разных компьютеров или браузеров, является , который считается другим.
- Государственные печенье смешивают с пользователем печеньем
Отделить печенье.
- Долгосрочные государственные печенья, например. текущий пользовательский идентификатор.
- состояния сеанса печенье
- печенье пользователя
Чтение, что ваш сайт только начинает рассматривать серверные куки означает, что сегрегация печенье еще не было сделано. Файлы cookie пользователя должны храниться на сервере как можно больше, так что, когда пользователь входит в систему на другом компьютере или в браузере, сохраняются предпочтения и корзины покупок. Ваша команда разработчиков должна принять решение о том, что некоторые файлы cookie, например, тележки для покупок, должны находиться между файлами cookie сеанса или пользователями.
печенье пользователя должно быть доступно через веб-сайт, независимо от места регистрации пользователя. Ваши разработчики должны решить, когда пользователь обновляет предпочтения или корзину, как немедленные должно быть видно, если это изменение тот же userId вошел в систему в другом месте.
Это означает, что вам необходимо реализовать систему распределенной базы данных. У вас есть сервер master db. Скажем, у вас есть 20 веб-серверов, каждый сервер с собственной базой данных.
Хранить только часто замененные куки на локальном диске и оставлять редко меняющиеся куки на главном компьютере.
Каждый раз, когда cookie обновляется на локальном db, обновленный флаг ставится в очередь для обновления хозяину. Запись файла cookie в главном устройстве не обновляется, только отмечена как устаревшая с номером местоположения, где находятся свежие данные. Таким образом, если этот userid каким-то образом активируется на расстоянии 3000 миль одновременно, этот сеанс будет обнаруживать устаревшие записи и запускать запрос на копирование из этих записей из нового местоположения в собственный локальный db, а master db и записи больше не помечены как устаревший на master db.
Затем вы планируете регулярную синхронизацию наиболее часто используемых куки-файлов cookie. Частота синхронизации может быть ночной или зависит от результата характеристики модификации файла cookie.
Во-первых, вашим программистам необходимо будет написать процедуру для регистрации всех файлов cookie для чтения/записи. Вы должны собрать неделю активности чтения/записи cookie для выполнения вашего первоначального анализа компонентов.
Выполняется простая статистическая характеристика для каждого файла cookie, userid и частоты изменения. Затем вы перемещаете свои предпочтения, определяя, какой файл cookie выталкивается ко всем локальным dbs и который остается на главном сервере. Решения уравновешивают размер блока cookie на локальных dbs и частоту синхронизации базы данных, которые вы готовы разрешить. Это означает, что не каждый пользователь имеет один и тот же набор файлов cookie. конечно, вашим программистам нужно будет писать процедуры для автоматизации регулярной рехарактеристики. Вместо того, чтобы использовать пользователя, вы можете облегчить загрузку загрузки cookie путем группировки своих пользователей с помощью кластерного анализа. Возможно, группировка пользователей для вашего сайта настолько очевидна, что вам не нужно выполнять кластерный анализ.
Вы можете быть удивлены, обнаружив, что большинство файлов cookie могут попадать в ведро с более длинным, чем еженедельно. Или в худшем случае, ежедневное обновление. и худший случай, который вы должны принять, - это ежечасное обновление для полей cookie, которые не помещаются на локальные dbs. Вы хотите увеличить шансы на доступ к файлам cookie на локальном db, а не на извлечение из основной базы данных. Поэтому, когда пользователь решает нажать «предпочтения», который редко изменяется, вы предварительно извлекаете записи предпочтений от мастера, отвлекая пользователя от некоторых излишеств, например: «Вы считали, что вы просматриваете нашу новую услугу?», «Хотите ли вы ответить наш обзор удобства использования? »,« новый Gibson rant, вы прокомментируете? »и т. д. до тех пор, пока куки« предпочтения »не будут скопированы.
Характеристика файлов cookie может быть выполнена для каждого пользователя или для каждого кластера пользователей, чтобы определить, какое поле cookie нужно перемещать в локальные dbs.
Проще всего охарактеризовать каждый пользовательский интерфейс, поскольку он едва ли использует навыки статистического анализа со стороны программиста. Недостатком является то, что веб-сервер должен будет принимать решения для каждого из 200 миллионов пользователей. В таблице базы данных печенье будет
Cookie[id, param, value, expectedMutationInterval].
веб-сервер Вы бы решить для каждого пользователя, который печенье толчок регулярно пороговым временем.
SELECT param, value
WHERE expectedMutationInterval < $thresholdTime
AND id = UserId
Вы должны выполнить регулярные recharacterization куки, чтобы обновить expectedMutationInterval на одного пользователя в куки. Простой SQL-запрос мог бы выполнить обновление expectMutationInterval.Более сложный анализ может быть выполнен для получения ожидаемого значенияMutationInterval.
Если каждое изменение куки поля регистрируется по времени, идентификатор пользователя и IPADDR тогда ваш стол журнала Cookie будет
CookieLog[id, time, ipaddr, param, value].
, который поможет вашей автоматизирована процедура recharacterization решить, какие поля нужно нажать в зависимости от DAYOFWEEK/месяц/сезон и местоположение/регион/ipaddr.
Затем, после удаления файлов cookie пользователя из браузера, если вы все еще находите свои файлы cookie sessison, вы теперь решаете, какие файлы cookie сеанса нужно нажимать на браузер и который остается на локальном сервере. Вы используете один и тот же метод анализа master-local db, но теперь используются для определения локального db и нажатия на браузер. Вы оставляете наименее часто используемые файлы cookie сеанса на локальном сервере, либо в качестве атрибутов сеанса, либо в db в памяти. Поэтому, когда клиент обнаруживает, что файл cookie отсутствует, он делает запрос на сервер для файла cookie, принося в жертву хотя бы недавно или часто используемое пространство для файлов cookie в браузере, чтобы разместить этот свежий файл cookie.
Поскольку это файлы cookie сеанса, их необходимо размножать в других местах, потому что, если один и тот же идентификатор пользователя зарегистрирован на расстоянии 3000 миль, он должен иметь свой собственный набор сеансовых файлов cookie.
Характеристика файлов cookie браузера - ирония, потому что для приложений 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 сеанса.
Итак, ваша компания ищет статистического программиста? Отказ от ответственности заключается в том, что это списано с манжетой и может потребоваться какая-то фактическая перегруппировка.
Это не временные данные сеанса, они постоянны. Подумайте, как Google хранит вашу информацию о пользователе при входе в систему и о том, как она доступна везде, где вы находитесь в сети. Мы использовали memecacheddb в прошлом, но с ключами 200M система беркелей начала разрушаться. –
У нас была аналогичная ситуация, когда мы перешли в наш центральный магазин сеансов. Наше решение добавило еще один физический ящик (и приложение для хранения), чтобы добавить второй независимый магазин. Мы сохраняем только данные сеанса в одном из полей и определяем, в каком поле находятся данные (sessionId% 2), чтобы узнать, где читать/записывать данные. Если мы хотим добавить третий ящик, это простой случай (sessionId% 3). –