Приложение чата Asp.net, использующее базу данных для очереди сообщений

Question

Я разработал веб-приложение для чата, которое использует базу данных SqlServer для обмена сообщениями.

Все клиенты опрашивают каждые x секунд, чтобы проверить наличие новых сообщений.

Очевидно, что этот подход потребляет много ресурсов, и мне было интересно, есть ли "более дешевый" способ сделать это.

Я использую тот же подход для «присутствия»: проверка, кто включен.

Answer 1

Без использования плагина / расширения для браузера, такого как flash или java-апплет, браузер по сути является средством односторонней связи. Запрос должен быть инициирован браузером для получения данных. Вы не можете «отправить» данные в браузер.

Многие веб-приложения используют метод опроса Ajax для имитации «проталкивания» сервера. Хитрость заключается в том, чтобы сбалансировать частоту / размер данных с пропускной способностью и ресурсами сервера.

Я просто сделал простое наблюдение за Gmail. Это делает опрос HttpPost каждые 5 секунд. Если нет изменения состояния, размер данных ответа составляет всего несколько байтов (не считая заголовки http). Конечно, у Google есть огромные ресурсы сервера и пропускная способность, поэтому я упоминаю: найти хороший баланс.

То есть «Улучшение взаимодействия с сервером». Возможно, вам придется использовать креативный способ стратегии опроса вместо простого опроса каждые х секунд.

например. Если нет активности от стороны A, опрос каждые 3 секунды. В то время как партия A печатает, проводите опрос каждые 5 секунд. Это просто иллюстрация, вы можете поиграть с числами или предложить более эффективный.

Наконец, обмен данными. Задача состоит в том, чтобы найти способ передать минимальные размеры данных для передачи той же информации.

мои 2 цента:)

Answer 2

Для чего-то вроде приложения чата в реальном времени я бы порекомендовал распределенный кеш с поддержкой SQL. Мне нравится memcached с провайдером Enyim .NET, поэтому я бы сделал что-то вроде следующего:

1. Сообщение пользователя
2. Система записывает сообщение в базу данных
3. Система записывает сообщение в кэш
4. Все пользователи периодически опрашивают кеш на наличие новых сообщений

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

Answer 3

Существует два связанных решения, встроенных в SQL Server 2005 и все еще доступных в SQL Server 2008:

1) Компонент Service Broker , который позволяет подписчикам публиковать операции чтения в очередях (команда RECEIVE с WAIT ..). В вашем случае вы захотите отправить свое сообщение через базу данных, используя Service Broker Services, стоящие перед этими очередями, которые затем могут быть получены ожидающими клиентами. Опрос отсутствует, ожидающие клиенты просто активируются при получении сообщения.

2) Уведомления о запросах , которые позволяют подписчику определять запрос, и получать уведомления, когда набор данных, который может возникнуть в результате выполнения этого запроса, изменится. Созданные на основе Service Broker, уведомления о запросах несколько проще в использовании, но также могут быть несколько менее эффективными. (Не то, чтобы уведомления о запросах и их братья и сестры, уведомления о событиях часто ошибочно принимаются за службы Notification Services (NS), что вызывает беспокойство, поскольку NS был выведен из эксплуатации в 2008 году, однако уведомления о запросах и событиях по-прежнему полностью доступны и даже улучшены в SQL Server 2008).

Answer 4

В ASP.NET 4.0 вы можете использовать шаблон наблюдателя с объектами и массивами JavaScript , то есть: вызовы JJ AJAX с jQuery и или PageMethods.

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

Answer 5

Если вы используете SQL Server 2005, вы можете посмотреть на Notification Services. Конечно, это заблокирует вас в SQL 2005, поскольку службы Notification Services были удалены в SQL 2008, и он был разработан, чтобы позволить SQL Server уведомлять клиентские приложения об изменениях в базе данных.

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

У рабочего процесса будет готов бит. Если это 1, тогда иди получать сообщения из таблицы сообщений. Если 0, ничего не делать.