Трансляция сообщений на высокой частоте.Использование 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: Задумывались ли вы об использовании хорошего гнезда?Либо вы открываете сокет для клиента, либо наоборот, и помещаете данные поверх этого?Это позволяет избежать накладных расходов HTTP и позволяет клиенту читать с той скоростью, с которой поступают данные.Если клиент больше не хочет получать данные, он может просто закрыть соединение.Это таинственная сторона, но она не позволит полностью убить целевой сервер.

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