Словарь адресов обратного вызова WCF с балансировкой нагрузки - PullRequest
0 голосов
/ 02 июня 2011

Текущая среда Мы используем модель Publisher / subscriber с использованием обратных вызовов WCF. У нас есть служба WCF, размещенная в IIS на одном веб-сервере. Любой клиент может подписаться / отписаться, вызвав методы обслуживания, и мы сохраняем / удаляем адрес обратного вызова соответственно с идентификатором клиента в словаре, т.е.

PrivateShared _currentSubscribeers As New Dictionary (из UShort, ICallbackService) ()

Словарь является статическим членом и используется в веб-приложении (в памяти не является постоянным)

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

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

Мы попытались сохранить в БД, но его нельзя сериализовать или использовать на другом сервере.

Мы потратили немного времени на поиск, но не нашли для этого решения, в котором мы могли бы поделиться адресом обратного вызова между серверами.

Может ли кто-нибудь помочь нам понять, как мы можем достичь этого? или любой другой вариант, который мы можем использовать?

Я был бы очень благодарен вам за вашу помощь. Жду вашего любезного ответа.

Ответы [ 2 ]

2 голосов
/ 13 сентября 2012

Ключ к вашему решению, вероятно, находится на стороне клиента.

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

Следовательно, выНЕ НУЖНО подключать клиента к обоим (т. е. ко всем) серверам, ему нужно только поддерживать соединение с одним из них.Это, конечно, означает, что, учитывая, что люди используют балансировку нагрузки для балансировки нагрузки, а не просто для обеспечения избыточности, у вас есть шанс, что одна машина будет обслуживать более половины ваших активных подключений.клиент этого не знаетТаким образом, ваш сервер может перерезать шнур так часто, специально, если не что иное, как заставить клиента отскочить (потенциально) от одного сервера к другому, постоянно распределяя нагрузку.Ваш клиент должен быть устойчивым к отключениям в любом случае, опять же, он не будет знать разницу.

1 голос
/ 02 июня 2011

Вы не можете разделить этот словарь обратного вызова между серверами. Каждый сервер должен иметь свой собственный словарь, поддерживающий своих клиентов, и поэтому вы должны использовать алгоритм балансировки нагрузки с привязкой к сессиям (липкие сессии). Этот алгоритм будет пересылать все запросы от одного клиента на один и тот же сервер.

...