где хранить состояние на сервере - PullRequest
0 голосов
/ 16 сентября 2010

Я разрабатываю функцию в своем приложении, в которой мне нужно хранить состояние определенной серии действий между двумя пользователями, как чат-сервис на основе ajax.

Сценарий выглядит следующим образом: Пользователь может видеть, какие другие пользователи находятся в сети, а затем вызвать одного из них. Другой пользователь получает вызов и принимает его. Теперь обоим пользователям задается 5 вопросов каждый, и для них начинается одновременное совпадение (почти одновременно). Затем, когда пользователь перемещается по вопросу или решает его, состояние также обновляется на экране другого пользователя.

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

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

Где я могу хранить состояние? Или на примере чата на основе Ajax, где я должен хранить то, что сообщение, введенное пользователем1, и когда введенное Uer1, как оно показывается пользователю2?

Я думал об объекте приложения, но прочитать его не рекомендуется.

Что вы порекомендуете для такой вещи?

1 Ответ

1 голос
/ 16 сентября 2010

Если вы пытаетесь выполнить передачу сообщений «почти в реальном времени», вам может понадобиться взглянуть на HTTP-опрос (он же длинный опрос).Я не буду использовать SQL для передачи временных сообщений и краткосрочных переходов состояний, как я видел в прошлом.При работе на одном веб-сервере просто сохраняйте состояние в сеансе или в кэше ASP.NET.При работе на нескольких веб-серверах обратите внимание на распределенные кэши, такие как memcached, Velocity (Win 2008) или NCache.Затем подайте кэшированные данные запросам AJAX, которые находятся в ожидании (из-за длительного опроса).Ключевой вопрос дизайна - это дизайн ключей кеша (без каламбура), который должен включать идентификатор пользователя для пользовательских данных о событиях.рассылка сообщений о времени, которые решают проблемы масштабирования, которые возникают, когда сотни клиентов одновременно участвуют в длинном опросе.Общее название этих структур - «Comet», и они наиболее полезны при рассылке одних и тех же сообщений многим клиентам.

...