Масштабируемость Websocket, проблемы вещания

Question

Если у вас есть сложные требования, установленные для множества пользователей (и серверов), как будет масштабироваться инфраструктура веб-сокетов (серверы), особенно с широковещательной рассылкой?

Конечно, вещание не является частью какой-либо спецификации websocket, но оно присутствует даже в основных примерах чата (a.k.a. hello world for websocket).

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

Edit:

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

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

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

Answer 1

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

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

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

Опрос HTTP может быть концептуально прощечтобы понять - вы можете поддерживать безгражданство и с каждым запросом HTTP-запроса вы указываете именно то, что вы ищете.Но это определенно означает, что вам нужно будет начать масштабирование гораздо раньше (добавив больше ресурсов для обработки нагрузки).

Опрос WebSocket - это то, что я раньше не рассматривал, и я не думаю, что виделэто предложило где-нибудь прежде либо;Идея, что клиент должен сказать: «Я готов к следующему набору данных и вот что я хочу», интересна.WebSockets, как правило, отошли от парадигмы запрос / ответ, но могут быть сценарии, в которых повышение эффективности WebSockets и использование запросов / ответов могут иметь некоторые преимущества.Платформа приложения SocketStream может стоить посмотреть, поскольку она может иметь отношение к делу;после начальной загрузки приложения вся связь осуществляется через WebSockets, что означает, что базовая функциональность запроса / ответа на событие использует WebSockets.

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

Answer 2

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

Похоже, вы хотите, чтобы каждый клиент постоянно отправлял запросы на сервер для получения новых данных. Зачем? Кажется, что это приведет к потере пропускной способности каждого, и я не знаю, почему вы думаете, что это будет более масштабируемым. Возможно, вы могли бы добавить больше деталей к вашему вопросу, например, какую информацию вы транслируете, как часто, сколько байтов, сколько клиентов и т. Д.

Почему бы просто не рассматривать открытое соединение через веб-сокет как постоянный запрос клиента на получение дополнительных данных?