Хорошее C # .NET решение для управления частыми опросами баз данных

Question

В настоящее время я работаю над настольным приложением c # .NET, которое будет взаимодействовать с базой данных через Интернет через службы WCF и WCF. В приложении будет много точек, которые, возможно, потребуется обновить через некоторый интервал. Самым простым решением было бы просто поместить эти области в таймер и запросить базу данных. Однако, поскольку тысячи клиентов подключаются к уровню обслуживания и, следовательно, к базе данных, эти операции будут очень дорогими для сервера.

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

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

Итак, мой вопрос в том, какие решения люди успешно применяют для решения этой проблемы? Люди сделали RSS? Службы синхронизации Microsoft? Двусторонняя связь между клиентом и сервером через какой-либо порт сохранения через WCF?

Любые идеи очень ценятся.

Answer 1

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

Новая технология, котораядовольно хорошо обрабатывает приведенное выше предложение в ASP.NET: SignalR .Это обрабатывает большую часть деталей длинного опроса (или использует WebSockets, когда это возможно), поэтому вам не нужно об этом беспокоиться.

Во-вторых, основываясь на тегах в этом вопросе, похоже, что вы используетеSQL Server.Вы можете использовать уведомления базы данных в таблицах, которые вас интересуют, чтобы БД уведомляла вашу службу о возникновении изменений.Это может затем вызвать службу, чтобы уведомить клиента об изменениях через длинные соединения опроса.Вы можете сделать это, используя класс SqlDependency .

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

Answer 2

вы можете определить интерфейс обратного вызова в соединении WCF следующим образом:

[ServiceContract(CallbackContract = typeof(IFooClient))]

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

IFooClient client = OperationContext.Current.GetCallbackChannel<IFooClient>();

и обратный вызов всех клиентов, которые зарегистрированы на изменения данных.

Answer 3

Я не знаю, почему RSS было бы проще, чем кэширование информации о ваших веб-сервисах из базы данных.

Чтобы сравнить 2 варианта, предположим, вам необходимо знать, кто редактировал объект в отчете в последний раз (или в последний раз, когда он обновлялся и т. Д.). С помощью RSS-канала вам нужно будет сделать запрос на фид, получить его, проанализировать и принять меры на основе соответствующих значений. При вызове веб-службы, который запоминает и кэширует вызов базы данных, вы просто вызываете службу и принимаете меры в отношении результата. Единственный раз, когда я мог видеть, что RSS лучше .

Answer 4

Вы можете посмотреть на Service Broker, так что вам не придется запрашивать обновления

Answer 5

Если дорогостоящей операцией является сервер для объединения в пул базы данных, вам следует реализовать какое-то кэширование. Это может быть как кэширование ASP.NET, так и расширенное использование memcached.

Но если дорогой операцией является клиент, объединяющий сервер, вы можете использовать Atom или RSS-канал с PubSubHubbub, чтобы минимизировать количество запросов к серверу. Это станет дешевле, поскольку есть несколько бесплатных издателей PubSubHubbub, которые справятся с нагрузкой.