Крупномасштабный стриминг видео с использованием Kubernetes и RabbitMQ

[baldr]

Рабочий поток NodeJS постоянно опрашивает очередь, дожидаясь новых задач как бравый солдат.

...

Такой поток продолжает опрашивать очередь RabbitMQ...

В очередной раз встречаю эту ошибку при описании работы с RabbitMQ.

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

А вот в случае с Apache Kafka, например - там, как раз, потребитель сам опрашивает очередь (скорее, список?) и забирает столько сообщений, сколько ему нужно и сам запоминает позицию.

[McFkr]

Ну смотря как реализован клиент.
Например, symfony messenger именно опрашивает очередь, поэтому в таком случае в UI самого кроля и не видно, сколько консьюмеров подключено к очереди

[baldr]

Нет, в AMQP нельзя "опрашивать очередь" и выбирать какие сообщения нравятся. Вы можете только получить первое же сообщение (или N сообщений), которое брокер решит назначить вашему консьюмеру. Я не знаю как именно реализован клиент в symfony messenger, но бегло посмотрел по докам и там, похоже, обычный AMQP-клиент. Не могу сказать почему он не показывается в списке, но должен, по идее.

[McFkr]

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

[baldr]

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

А можете пример привести?

UPD: Согласен, похоже, что basic.get так работает. Я думал что там тоже через consuming оно идет.

[McFkr]

Вот только зашел чтоб про этот метод сказать) По сути можно в одном воркере реализовывать что-то типо приоритета очередей, когда 1 воркер работает сразу с несколькими очередями (к примеру для различного рода рассылок и нотификаций)

[baldr]

Ну можно, наверное, но тогда теряется куча фич - типа late ack, да и вообще медленнее это гораздо, чем подписка. basic.get может быть удобен именно при одноразовом подключении - типа периодического поллинга с веба или с мобильного, когда подключение держать неудобно.

[svok]

НИКОГДА и ни при каких обстоятельствах не используйте rabbit и kafka при работе с мультимедиа! Не пройдете по производительности, а если и пройдете, то на ресурсах разоритесь и задержки будут чрезмерные, причем, нарастающие со временем.

Материалов, описывающих работу с потоковым видео полно, если знать ключевые слова. И ключевые слова здесь ffmpeg, gstreamer и opencv. Это три фреймворка, которые тесно между собой переплетены. Все написаны на C, все работают с протоколами и кодеками различных медиа-потоков, поддерживают все, что необходимо.

[baldr]

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

Однако, по картинкам видно, что стриминг самого потока идет вообще через CDN, а RabbitMQ используется в задачах при загрузке и обработке видео. Заголовок не совсем отражает суть статьи.

[svok]

Любую обработку надо делать на указанных фреймворках. Rmq вообще для видео не подходит. Это как молотком в зубах ковыряться.

[strelkove]

А без CDN вообще вряд ли получится реализовать хоть сколько-то масштабный стриминг. Иначе всё упрётся не столько в ресурсы, сколько в пропускную способность сети конкретного кластера.

[gasevskyv]

А что не так? Если я правильно понял - rmq используется для задач на обработку видео. Вроде норм

[baldr]

Да, для задач на обработку частей видео в фоне, в очереди. За "крупномасштабный стриминг" он не отвечает.

[crewalink]

Схемы достаточно наглядно разжовывают информацию, благодаря ним становится понятнее!

[Chess]

Спасибо, интересно.

Пару вопросов:

1. Почему Rabbit + отдельный layer "порождающих" подов, а не Pub/Sub + Cloud Functions (SQS + Lambdas)?

2. Вы уже используете Redis, почему тогда не Redis Streams вместо Rabbit?

3. Если только вытесняемые инстансы, не возникает ли проблем в часы пик? Не лучше ли микс из вытесняемых + гарантированные?

[baldr]

Я не автор, но разрешите мне прокомментировать с моей точки зрения.

1. Не все любят завязывать всё на облачные решения. Они не всегда оптимальны, в том числе, по цене. Вполне возможно, что уже была часть работы на выделенных серверах через RabbitMQ-воркеры и просто добавили это туда.

2. Ну, теоретически, доставка через Redis менее надёжна. Хотя, в целом, наверное, вполне подойдёт для таких задач. Опять же, киллер-фича RabbitMQ - это его роутинг через exchange/queue/routing_key. Плюс более удобный UI для менеджмента всего этого. Очень часто архитектурные решения принимаются просто, учитывая опыт команды - Redis Streams вышел в конце 2018г, а RabbitMQ используется на 10 лет дольше.

3. Хороший вопрос. Думаю, возникает. И да - наверное лучше. И, вполне возможно, что так и делается.

Lambda - удобная в чём-то штука, но может выжрать бюджет быстрее, чем пара спокойных серверов, неспешно прожёвывающих задачи из неприоритетной очереди. Особенно если там что-то обрабатывает ffmpeg или что-то, требующее GPU или несколько ядер.

[Chess]

Спасибо, прекрасный, обоснованный ответ.

Про Lambda уточню, что я имел в виду, что они заменяют порождающий (triggering) layer, а не workers для video processing. Иначе все будет работать очень дорого и плохо :)