По большей части мой опыт связан со «статическими» интерфейсами JavaScript, взаимодействующими со стеком Django с внутренними интерфейсами Python. Здесь есть множество способов сделать эту работу, где одна из наиболее распространенных парадигм заключается в передаче запросов «без сохранения состояния» (или «Restful») группе рабочих, которые затем отправляют ответ (когда это делается) чему-то вроде Redis. для скорости. Затем передняя часть должна повторно запрашивать серверную часть, чтобы узнать, завершена ли ее задача (с уникальным идентификатором, который был возвращен от работника). Если да, новую страницу (или данные) можно получить из задний конец.
У меня такой вопрос. Как на самом деле работает потоковое видео? Упрощенно можно представить себе одну копию популярного телешоу (например, «Игры престолов»), которое несколько рабочих (по одному на пользователя) непрерывно читают и передают. На практике, однако, возникнет узкое место на сервере, поскольку одновременно могут происходить сотни тысяч операций чтения одного и того же файла данных.
Можно представить, что в этом есть больше ума. Например, для очень популярного контента вы можете запускать новый поток каждые 5-10 секунд. Затем каждый пользователь, который запрашивает шоу, будет ждать эти 5-10 секунд (самое большее), а затем подключаться к потоковой трансляции для сотен пользователей. Во внешнем интерфейсе вы можете приостанавливать, перематывать и т. Д., Но пока у получателя достаточно памяти и он остается подключенным к назначенному экземпляру потока, все это будет обрабатываться на внешнем компьютере (что, по сути, , продолжайте получать и сохранять данные на локальном компьютере или видеоустройстве, а также имитировать паузу, перемотку назад и т. д. - при этом вы не можете перемотать вперед дальше самого последнего полученного видеокадра).
Может ли кто-нибудь объяснить, как это работает на практике? Один поток на пользователя кажется абсурдным ответом на популярный контент. Какова фактическая архитектура потоковой передачи по запросу?