Вещательные сообщения на высокой частоте. Использование HTTP POST или что-то еще?

Question

Мы рассматриваем систему, которая передает небольшие количества часто изменяющихся данных (используя JSON или XML или что-то еще) для нескольких получателей на достаточно высокой частоте (наши обновления будут 1000 с в секунду).

Мы изначально думали использовать HTTP POST для трансляции данных на каждую конечную точку, возможно, раз в несколько секунд (клиенты будут меняться, так как они являются веб-приложениями других людей), но теперь нам интересно, есть ли лучший способ чтобы поддерживать нагрузку/частоту, которую мы надеемся. Я полагаю, что нам нужно как-то модифицировать или опознать сообщения.

Мы используем RabbitMQ для подготовки всех вещей, готовых к отправке, и для выбора того, что нужно делать (от приложения Django, если это имеет значение), но мы не можем заставить все конечные точки использовать MQ ,

HTTP POST вещь просто не совсем правильная. Что еще мы должны искать? Это где вещи, такие как node или socket.io или некоторые из новых фреймворков реального времени? Мы рады найти подходящий опыт, чтобы помочь с этим, просто нужно руководствоваться правильным направлением.

Спасибо!

Answer 1

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

Вариант 1: для клиентов, которые не могут или не будут читать очередь, POSTS может работать, но чтобы избежать убийства сервера и всех накладных расходов HTTP, вы могли бы рассказать об обновлениях? Как только каждую минуту или две, возьмите все совокупные данные, а затем отправьте их клиенту? Таким образом, у вас нет 60+ POST-запросов, которые будут отправляться одному клиенту каждую минуту или две на время и на вечность. Это также поможет сэкономить на пропускной способности, поскольку вы только отправляете всю информацию заголовка один раз с большим количеством данных, а не отправляете всю информацию заголовка и фрагменты данных.

Вариант 2: Вы думали об использовании хорошего соединения с разъемом ole? Либо вы открываете сокет клиенту, либо наоборот, и нажимаете на него данные? Это позволяет избежать накладных расходов на HTTP и позволяет клиенту считывать данные о скорости. Если клиент больше не хочет получать данные, они могут просто закрыть соединение. Он находится на тайной стороне, но это позволит полностью уничтожить целевой сервер.

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