описание:

• интро
• архитектура сервера
• архитектура клиент
• случае обновления
• совершить дело
• случае конфликта
• производительность и масштабируемость

Привет Raynos,

Я не буду обсуждать какой-либо конкретный продукт здесь. То, что другие упоминали, - это хороший набор инструментов, на который уже можно взглянуть (возможно, добавить узел.js к этому списку).

от архитектурная точка зрения, похоже, у вас есть та же проблема, что и в программном обеспечении контроля версий. Один пользователь проверяет изменение объекта, другой пользователь хочет изменить тот же объект другим способом => конфликт. Вы должны интегрировать изменения пользователей в объекты, одновременно обеспечивая своевременную и эффективную доставку обновлений, обнаруживая и разрешая конфликты, подобные приведенному выше.

Если бы я был на вашем месте, я бы развил что-то вроде этого:

1. Серверная Сторона:

• определите разумный уровень, на котором вы определили бы то, что я бы назвал "атомными артефактами" (страница? Объекты на странице? Значения внутри объектов?). Это будет зависеть от ваших веб-серверов, базы данных и оборудования кэширования, # пользователя, # объектов и т. д. Нелегкое решение.

• для каждого атомарного артефакта есть:

  • приложение-широкий уникальный id
  • инкрементный версия-код
  • механизм блокировки для доступа на запись (возможно, мьютекс)
  • небольшая история или "список изменений" внутри ringbuffer (общая память хорошо работает для них). Одна пара ключ-значение может быть в порядке, хотя и менее расширяемой. см.http://en.wikipedia.org/wiki/Circular_buffer

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

2. Сторона Клиента:

• клиент javascript, который может иметь длительное HTTP-соединение с указанным выше сервером или использует легкий опрос.

• компонент javascript artifact-updater, который обновляет содержимое сайтов, когда подключенный клиент javascript уведомляет об изменениях в истории наблюдаемых артефактов. (опять же, шаблон наблюдателя может быть хорошим выбор)

• компонент JavaScript artifact-committer, который может запросить изменение атомарного артефакта, пытаясь получить блокировку мьютекса. Он определит, было ли состояние артефакта изменено другим пользователем за несколько секунд до этого (латансия клиента javascript и фиксация факторов процесса) путем сравнения известного артефакта на стороне клиента-version-id и текущего артефакта на стороне сервера-version-id.

• решатель конфликтов javascript, позволяющий человеку какое-изменение-правильное решение. Вы не можете просто сказать пользователю: "кто-то был быстрее вас. Я удалил твою сдачу. Иди поплачь.". Многие варианты из довольно технических различий или более удобных решений кажутся возможными.

Итак, как он будет катиться ...

Случай 1: вид последовательности диаграмм для обновления:

• браузер отображает страницы
• javascript "видит" артефакты, каждый из которых имеет хотя бы одно поле значений, уникальное-и версия-код
• клиент javascript запускается, запрашивая "посмотреть" историю найденных артефактов, начиная с их найденных версий (старые изменения не интересны)
• серверный процесс отмечает запрос и непрерывно проверяет и / или отправляет историю
• записи истории могут содержать простые уведомления "артефакт x изменился, данные запроса клиента pls", позволяющие клиенту опрашивать независимо или полные наборы данных " артефакт x изменился на значение foo"
• JavaScript artifact-updater делает все возможное, чтобы получить новые значения, как только станет известно, что они обновлены. Он выполняет новые запросы ajax или получает питание от клиента javascript.
• страницы DOM-content обновляется, пользователь дополнительно уведомляется. Наблюдение за историей продолжается.

случай 2: Теперь для совершения:

• artifact-committer знает желаемое новое значение из пользовательского ввода и отправляет запрос на изменение сервер
• приобретен мьютекс serverside
• сервер получает " Эй, я знаю состояние артефакта x от версии 123, позвольте мне установить его в значение foo pls."
• если серверная версия артефакта x равна (не может быть меньше) 123, принимается новое значение, генерируется новый идентификатор версии 124.
• новое состояние-информация "обновлено до версии 124" и, возможно, новое значение foo помещаются в начале ringbuffer артефакта x (журнал изменений/история)
• выпущен мьютекс serverside
• запрашивающий фиксатор артефактов рад получить подтверждение фиксации вместе с новым идентификатором.
• тем временем серверный серверный компонент поддерживает опрос/толкает ringbuffers для подключенных клиентов. Все клиенты, наблюдающие за буфером артефакта x, получат новую информацию о состоянии и значение в пределах своей обычной задержки (см. случай 1.)

Случай 3: для конфликты:

• Artifact committer знает желаемое новое значение из пользовательского ввода и отправляет запрос на изменение на сервер
• тем временем другой пользователь успешно обновил тот же артефакт (см. случай 2.) но из-за различных задержек это еще неизвестно нашему другому пользователю.
• таким образом, серверный мьютекс приобретается (или ждал, пока "более быстрый" пользователь не совершит свое изменение)
• сервер получает " Эй, я знаю состояние артефакта x из версии 123, позвольте мне установить значение foo."
• на стороне сервера версия артефакта x теперь уже 124. Запрашивающий клиент не может знать значение, которое он будет перезаписывать.
• очевидно, что сервер должен отклонить запрос на изменение (не считая приоритетов перезаписи с вмешательством Бога), освобождает мьютекс и достаточно любезен, чтобы отправить обратно новый идентификатор версии и новое значение непосредственно клиенту.
• столкнулся с отклоненным запросом фиксации и значением пользователь, запрашивающий изменение, еще не знал, что фиксатор артефактов javascript ссылается на распознаватель конфликтов, который отображает и объясняет проблему пользователю.
• пользователь, будучи представлены некоторые варианты смарт-конфликт-резолвер в JS, допускается еще одна попытка изменить значение.
• как только пользователь выбрал значение, которое он считает правильным, процесс начинается с случая 2 (или случая 3, Если кто-то другой был быстрее, снова)

несколько слов о производительности & Масштабируемость

HTTP Polling vs. HTTP"pushing"

• опрос создает запросы, один в секунду, 5 в секунду, независимо от того, что вы считаете приемлемой задержкой. Это может быть довольно жестоко для вашей инфраструктуры, если вы не настроите свой (Apache?) и (РНР?) достаточно хорошо, чтобы быть" легкими " стартерами. Желательно оптимизировать запрос опроса на стороне сервера, чтобы он выполнялся в течение гораздо меньшего времени, чем длина интервала опроса. Разделить это время выполнения в два раза может означать снижение всей нагрузки системы до 50%,
• нажатие через HTTP (предполагая, что веб-рабочие слишком далеки, чтобы поддерживать их) потребует от вас одного процесса apache/lighthttpd для каждого пользователя все время. Резидентная память, зарезервированная для каждого из этих процессов, и общая память вашей системы будут одним очень определенным ограничением масштабирования, с которым вы столкнетесь. Уменьшение объема памяти соединения будет необходимо, так как а также ограничение количества непрерывной работы процессора и ввода-вывода в каждом из них (вы хотите много сна/простоя)

бэкэнд масштабирование

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

интерфейс масштабирование

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

"творческих" настроек

• если клиенты опрашивают и многие пользователи склонны смотреть те же артефакты, вы можете попытаться опубликовать историю этих артефактов как статический файл, позволяющий apache кэшировать его, тем не менее обновляя его на стороне сервера при изменении артефактов. Это выводит PHP / memcache из игры для некоторых запросов. Lighthttpd очень эффективен при обслуживании статических файлов.
• используйте сеть доставки контента, например cotendo.com чтобы протолкнуть туда историю артефактов. Толчок-задержка будет больше, но масштабируемость-это мечта
• напишите реальный сервер (не используя HTTP), к которому пользователи подключаются с помощью java или flash (?). Ты должен разобраться. с обслуживанием многих пользователей в одном сервере-потоке. Езда на велосипеде через открытые сокеты, выполнение (или делегирование) требуемой работы. Может масштабироваться с помощью процессов разветвления или запуска нескольких серверов. Однако мьютексы должны оставаться глобально уникальными.
• в зависимости от сценариев загрузки сгруппируйте интерфейсные и серверные серверы по диапазонам идентификаторов артефактов. Это позволит лучше использовать постоянную память (ни одна база данных не имеет всех данных) и позволяет масштабировать мьютексинг. Ваш javascript должен поддерживать соединения с несколькими серверами одновременно.

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

Кристоф Стразен