Трансляция данных между экземплярами распределенного сервера

Question

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

Параметры, которые я пытаюсь исследовать:

1. Redis / Zookeeper / Doozer - каждый экземпляр сервера регистрируется на сервере конфигурации, и все подключенные серверы будут получать обновления конфигурации при его изменении. Что тогда?
   1. Поддерживать сквозные соединения с каждым экземпляром сервера и перебирать список со всеми исходящими данными?
   2. Некоторая пользовательская многоадресная рассылка UDP, но мне нужно было бы добавить собственную надёжность поверх нее.
2. Пользовательский брокер сообщений - служба, которая запускает и поддерживает реестр при подключении и информировании каждого сервера. Поддерживает соединение с каждым сервером, чтобы принимать данные и повторно передавать их на другие серверы.
3. Некоторый надежный многоадресный транспорт UDP, при котором каждый экземпляр сервера просто вещает напрямую и реестр не поддерживается.

Вот мои проблемы:

• Я бы не хотел полагаться на внешние приложения, такие как zookeeper или doozer, но я бы использовал их, очевидно, если это лучшее решение
• С пользовательским брокером сообщений я бы не хотел, чтобы он стал узким местом для пропускной способности. Что может означать, что мне, возможно, придется иметь возможность запускать несколько брокеров сообщений и использовать балансировщик нагрузки при масштабировании?
• multicast не требует никаких внешних процессов, если мне удастся свернуть свои собственные, но в противном случае мне, возможно, придется использовать ZMQ, что снова ставит меня в ситуацию зависимости.

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

* РЕДАКТИРОВАНИЕ цели *

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

1. Каждый экземпляр сервера поддерживает постоянные соединения сокетов TCP со своими удаленными клиентами и передает сообщения между ними.
2. Сообщения должны быть в состоянии транслироваться другим работающим экземплярам, ​​чтобы их можно было доставлять в соответствующие клиентские соединения.
3. Низкая задержка важна, потому что обмен сообщениями может быть быстрым.
4. Последовательность и надежность важны.

* Обновленная сводка вопросов *

Если у вас есть несколько серверов / несколько конечных точек, которые должны публиковать / размещать между собой, какой режим связи рекомендуется между ними? Один или несколько брокеров сообщений повторно публикуют сообщения в списке обнаруженных серверов? Надежная многоадресная рассылка напрямую с каждого сервера? Как соединить несколько конечных точек в распределенной системе, сохраняя низкую задержку, высокую скорость и надежность доставки?

Answer 1

Предполагая, что все ваши конечные точки, обращенные к клиенту, находятся в одной и той же локальной сети (которой они могут быть для первого разумного шага в масштабировании), надежная многоадресная UDP-передача позволит вам отправлять опубликованные сообщения непосредственно из конечной точки публикации в любую из конечных точек.у которых клиенты подписались на канал.Это также удовлетворяет требованию низкой задержки намного лучше, чем проксирование данных через уровень постоянного хранения.

Группы многоадресной рассылки

• Центральная база данных (скажем, Redis)может отслеживать карту групп многоадресной рассылки (IP: PORT) <-> каналов.
• Когда конечная точка получает нового клиента с новым каналом для подписки, она может запросить у базы данных адрес многоадресной рассылки канала и присоединитьсягруппа многоадресной рассылки.

надежная многоадресная рассылка UDP

• Когда конечная точка получает опубликованное сообщение для канала, она отправляет сообщение на многоадресную рассылку этого канала.socket.
• Пакеты сообщений будут содержать упорядоченные идентификаторы на сервер на группу многоадресной рассылки.Если конечная точка получает сообщение без получения предыдущего сообщения от сервера, она отправляет сообщение «не подтверждено» для всех пропущенных сообщений обратно на сервер публикации.
• Сервер публикации отслеживает список последних сообщенийи повторно отправляет сообщения NAK'd.
• Для обработки пограничного случая сервера, отправляющего только одно сообщение и не имеющего доступа к серверу, сервер может отправлять число пакетов в группу многоадресной рассылки в течение срока их службы.Очередь NAK: «Я отправил 24 сообщения», предоставляя другим серверам шанс получить NAK предыдущие сообщения.

Возможно, вы захотите просто внедрить PGM.

Постоянное хранилище

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