Масштабирование / объединительная плата SignalR в реализации широковещательной рассылки сервера - не вызовет ли это дублирование сообщений для клиентов?

В документации SignalR говорится, что масштабирование / объединительная плата хорошо работает в случае типа загрузки / реализации серверного вещания. Однако я сомневаюсь, что в случае чисто серверной трансляции это вызовет отправку дублирующих сообщений клиентам. Рассмотрим следующий сценарий:

  1. У меня есть два экземпляра моего концентратора, расположенные на двух веб-серверах за балансировщиком нагрузки на моей веб-ферме.
  2. Хаб на каждом сервере реализует таймер для опроса базы данных для получения некоторых обновлений и широковещательной рассылки клиентам в группах, сгруппированных по идентификатору темы.
  3. Клиенты группы / темы могут быть разделены между двумя серверами.
  4. Оба экземпляра концентратора будут получать одинаковые или перекрывающиеся обновления из базы данных.
  5. Теперь, когда каждый концентратор отправляет обновления клиентам через объединительную плату, не приведет ли это к отправке дублирующих обновлений клиентам?

Пожалуйста, предложите.


person Nagesh Chopra    schedule 04.04.2015    source источник
comment
Зачем тебе нужно время ?? вы можете использовать средство уведомления об обновлении sql или метод ручного запуска. вы можете взглянуть на этот github.com/ anik123 /   -  person Anik Islam Abhi    schedule 05.04.2015
comment
@AnikIslamAbhi: Мое приложение предназначено для общения в реальном времени и будет иметь очень высокую частоту обновлений, и я не хочу, чтобы меня переполняли уведомления об обновлениях или триггеры. Вместо этого мне нужен интервальный пул для получения и отправки обновлений клиентам, не вызывая очень большого количества подключений к базе данных с принимающей стороны.   -  person Nagesh Chopra    schedule 07.04.2015
comment
говоря, ручной триггер, я хочу иметь в виду, что уведомление о действии пользователя, например, если пользователь что-то вставляет. затем отправить всем уведомление об обновлении   -  person Anik Islam Abhi    schedule 07.04.2015
comment
Я реализовал что-то вроде этого. проверьте мою предоставленную ссылку на github   -  person Anik Islam Abhi    schedule 07.04.2015
comment
@ Anik-Islam-Abhi: Таким образом, ручной триггер делает его управляемым событиями пользователя или клиент-клиентским сценарием / приложением, а не серверным вещанием. Меня беспокоит документация, в которой говорится, что объединительная плата может быть узким местом в случае сценария клиент-клиент. Ссылка: asp.net/signalr/overview/older-versions/ scaleout-in-signalr   -  person Nagesh Chopra    schedule 07.04.2015


Ответы (1)


Проблема не в SignalR, а в том, что ваш опрос базы данных находится внутри ваших хабов. Объединительная плата правильно работает с широковещательной репликацией, но если вы добавите еще одну ответственность к своим концентраторам, то это совсем другая история. Это часть, которая дублирует сообщения, а не SignalR, потому что теперь у вас есть N опросчиков, выполняющих широковещательную рассылку по всем экземплярам сервера.

Вы можете, например, удалить эту логику из концентраторов во что-то еще и позволить только одному экземпляру ваших серверных приложений использовать эту новую часть для генерации сообщений путем опроса, используя, возможно, часть конфигурации, чтобы решить, какой из них . Таким образом, вы будете отправлять сообщения только оттуда, а объединительная плата SignalR позаботится о репликации. Это просто очень простое предложение, и его можно было бы сделать по-другому, но ключевым моментом является то, что ваш опросчик не должен реплицироваться, и это не имеет прямого отношения к SignalR.

Также верно, что опрос может быть не лучшим способом справиться с вашим сценарием, но ИМО, это ответит на другой вопрос.

person Wasp    schedule 05.04.2015
comment
В этом есть смысл. У меня действительно была эта идея, но я был обеспокоен тем, что если один сервер, на который возложена дополнительная ответственность за выборку и рассылку обновлений, выйдет из строя, приложение остановится. Это может означать реализацию отдельной логики для мониторинга активности этого первого сервера и второго сервера для ее отслеживания, чтобы он мог взять на себя дополнительную ответственность, если первый сервер не работает. - person Nagesh Chopra; 07.04.2015
comment
Я, вероятно, также могу реализовать сценарий клиент-клиент вместо широковещательной передачи. Но мне любопытно узнать, где действительно имеет смысл сценарий широковещательной передачи с объединительной платой SiganlR в веб-ферме, если ответственность за широковещательную передачу должна быть возложена только на один сервер? - person Nagesh Chopra; 07.04.2015
comment
Это имеет смысл для любой трансляции, инициированной клиентом (подумайте о системе чата, в которой один пользователь хочет поздороваться со всеми). Это также имеет смысл, если у вас есть N-сервер, который не просто выполняет функции SignalR, и любой из них может выполнять традиционный HTTP за балансировщиком нагрузки, в таком случае у вас может быть HTTP POST, поражающий один конкретный сервер и генерирующий широковещательную рассылку. Проблема, которая у вас есть, специфична для вашего случая, и ваши комментарии имеют смысл, но есть много других случаев, когда широковещательные передачи инициируются извне системы, и они прекрасно работают с объединительной платой. - person Wasp; 07.04.2015
comment
Я думаю, что инициируемая клиентом трансляция (например, чат), как вы говорите, скорее является сценарием клиент-клиент или пользовательским событием, а не сценарием широковещательной передачи сервера. Ссылка: asp.net/signalr/overview/older-versions/ scaleout-in-signalr Мое приложение действительно представляет собой похожий сценарий, управляемый событиями пользователя, включая чат в дополнение к другой основной функции, которая генерирует очень частые обновления от нескольких пользователей к группам других пользователей. И я был обеспокоен документацией (см. Ссылку выше), в которой говорилось, что объединительная плата может быть узким местом в сценарии клиент-клиент. - person Nagesh Chopra; 07.04.2015
comment
И поэтому я думал о том, чтобы реализовать его как широковещательную передачу сервера, где сообщения / обновления не доставляются целевым клиентам / группе напрямую и немедленно, как они получены от исходного клиента, но сервер должен контролировать передачу к целям посредством регулярного опроса обновлений от БД. Пока я думаю, что в сценарии трансляции SignalR веб-ферма поможет увеличить мощность серверов только на макс. соединений и нагрузки, но он не может обеспечить резервирование в случае отказа узла из коробки. - person Nagesh Chopra; 07.04.2015
comment
Согласен. Я воспринял ваш вопрос в комментариях скорее как общий вопрос, не связанный строго с серверным контекстом. То, что вы говорите, имеет смысл, поэтому я предполагаю, что вам придется искать решение, в котором стратегия опроса живет снаружи и ее должным образом дублируют. Или вы принимаете тот факт, что сообщения могут дублироваться, и реализуете стратегию на стороне клиента, чтобы исключить дублирование, то есть со стратегией TTL. Может быть флуд? Да, но может и нет, это зависит от размера вашей системы, и это может быть приемлемо (иногда так), чего я не могу сказать. - person Wasp; 07.04.2015