Проектирование службы потокового видео по запросу

Некоторые популярные на сегодняшний день варианты службы потокового видео по запросу:

• Ютуб
• Нетфликс
• Вимео
• ТикТок

Требования

• Пользователь может загружать видеофайлы
• Пользователь может транслировать видеоконтент
• Пользователь может искать видео по названию видео.

Хранение данных

Схема базы данных

* Основными объектами являются видео, пользователи и таблицы комментариев. * Отношения между пользователями и видео - 1 ко многим * Связь между пользователями и таблицей комментариев 1 ко многим * Связь между видео и таблицей комментариев 1 ко многим

n Тип сохраняемых данных

* Хранилище данных с широкими столбцами (LSM на основе дерева), такое как Apache HBase используется для сохранения эскизов изображений для объединения файлов, отказоустойчивости и репликации. * Кэш-сервер, такой как Redis, используется для хранения метаданных популярного видеоконтента. * Очередь сообщений, такая как Apache Kafka, используется для асинхронной обработки (кодирования) видео. * Реляционная база данных, такая как MySQL, хранит метаданные пользователей и видео. * Видеофайлы хранятся в управляемом хранилище объектов, таком как AWS S3 * Хранилище данных инвертированного индекса на основе Lucene, такое как Apache Solr, используется для сохранения данных индекса видео для обеспечения функции поиска

Дизайн высокого уровня

• Популярный видеоконтент передается из CDN.
• Кодирование видео (транскодирование) – это процесс преобразования формата видео в другие форматы (MPEG, HLS) для обеспечения наилучшего качества потоковой передачи на нескольких устройствах и с разной пропускной способностью.
• Очередь сообщений можно настроить между службами для обеспечения параллелизма и повышения отказоустойчивости.
• Кодеки (H.264, VP9, ​​HEVC) – это алгоритмы сжатия и распаковки, используемые для уменьшения размера видеофайла при сохранении качества видео.
• Популярные протоколы потоковой передачи видео (стандарт передачи данных): MPEG-DASH (Группа экспертов по движущимся изображениям  — «Динамическая адаптивная потоковая передача через HTTP»), Apple HLS (HTTP Live Streaming ), Microsoft Smooth Streaming и Adobe HDS (HTTP Dynamic Streaming)

Рабочий процесс загрузки видео

1. Пользователь (клиент) выполняет DNS-запрос для идентификации сервера
2. Клиент устанавливает HTTP-соединение с балансировщиком нагрузки.
3. Запросы на загрузку видео ограничены по скорости для предотвращения вредоносных клиентов.
4. Балансировщик нагрузки делегирует запрос клиента серверу API (веб-серверу) со свободной емкостью
5. Веб-сервер делегирует запрос клиента серверу приложений, который обрабатывает конечную точку API.
6. Идентификатор загруженного видео сохраняется в очереди сообщений для асинхронной обработки видеофайла.
7. Название и описание (метаданные) видео хранятся в базе данных метаданных.
8. Сервер приложений запрашивает службу хранилища объектов, чтобы сгенерировать предварительно подписанный URL-адрес для хранения необработанного видеофайла.
9. Клиент загружает необработанный видеофайл непосредственно в хранилище объектов, используя предварительно подписанный URL-адрес, чтобы сэкономить пропускную способность сети системы.
10. Серверы транскодирования запрашивают очередь сообщений, используя шаблон публикации-подписки, чтобы получать уведомления о загруженных видео.
11. Сервер транскодирования извлекает необработанный видеофайл, запрашивая хранилище необработанных объектов.
12. Сервер перекодирования перекодирует необработанный видеофайл в несколько кодеков и сохраняет перекодированный контент в хранилище перекодированных объектов.
13. Сервер миниатюр создает в среднем пять миниатюр для каждого видеофайла и сохраняет созданные изображения в хранилище миниатюр.
14. Сервер перекодирования сохраняет идентификатор перекодированного видео в очереди сообщений для дальнейшей обработки.
15. Служба обработчика загрузки запрашивает очередь сообщений с помощью шаблона публикации-подписки, чтобы получать уведомления о перекодированных видеофайлах.
16. Служба обработчика загрузки обновляет базу метаданных метаданными перекодированных видеофайлов.
17. Служба обработчика загрузки запрашивает службу уведомлений, чтобы уведомить клиента о состоянии обработки видео.
18. Базу данных можно разделить с помощью непротиворечивого хеширования (ключ = идентификатор пользователя или идентификатор видео)
19. Сопоставление блоков или Алгоритмы фазовой корреляции могут использоваться для обнаружения дублирующегося видеоконтента
20. Веб-сервер (сервер API) должен оставаться без отслеживания состояния для масштабирования посредством репликации.
21. Видеофайл хранится в нескольких разрешениях и форматах для поддержки нескольких устройств и пропускной способности.
22. Видео может быть разделено клиентом на более мелкие фрагменты перед загрузкой, чтобы поддерживать возобновление прерванных загрузок.
23. Для защиты видеоконтента можно использовать водяные знаки и шифрование.
24. Центры обработки данных добавляются для уменьшения задержки и восстановления данных за счет увеличения рабочих процессов обслуживания.
25. Очередь недоставленных сообщений можно использовать для повышения отказоустойчивости и обработки ошибок.
26. Инженерия хаоса используется для выявления сбоев в сетях, серверах и приложениях.
27. Нагрузочное тестирование и хаос-инжиниринг используются для повышения отказоустойчивости.
Конфигурация
28. RAID повышает пропускную способность оборудования
29. Хранилище данных разделено на разделы для распределения операций записи и чтения за счет сложных соединений, транзакций и толстого клиента.
30. Федерация и сегментирование используются для масштабирования базы данных.
31. Запросы на запись перенаправляются к лидеру, а запросы на чтение перенаправляются к подписчикам базы данных.
32. Vitess – промежуточное ПО для хранения данных, предназначенное для масштабирования MySQL
.
33. Vitess перенаправляет запросы на чтение, требующие свежих данных, руководителю (например, операция обновления профиля пользователя)
34. Vitess использует сервер блокировки (Apache Zookeeper) для автоматического сегментирования и выбора лидера на уровне базы данных.
35. Vitess поддерживает соединения, индексирование и транзакции на основе RPC в базе данных SQL.

36. Vitess позволяет разгрузить логику разделения из приложения и улучшает запросы к базе данных за счет кэширования

n Рабочий процесс потокового видео

1. Клиент выполняет DNS-запрос для идентификации сервера.
2. Клиент устанавливает HTTP-соединение с балансировщиком нагрузки.
3. К сети CDN отправляется запрос, чтобы убедиться, что запрошенный видеоконтент находится в кеше CDN.
4. CDN запрашивает перекодированный объект, сохраненный при промахе кеша.
5. Балансировщик нагрузки делегирует запрос клиента веб-серверу со свободной емкостью, используя взвешенный циклический алгоритм.
6. Веб-сервер делегирует запрос клиента серверу приложений, используя последовательное хеширование.
7. Сервер приложений запрашивает кэш метаданных, чтобы получить метаданные видео.
8. Сервер приложений запрашивает базу данных метаданных при промахе кэша.
9. Сервер приложений запрашивает хранилище миниатюр, чтобы получить соответствующие миниатюры видео.
10. Сервер приложений запрашивает хранилище перекодированных объектов, чтобы получить видеоконтент.
11. Сервер приложений делегирует поисковые запросы клиента хранилищу инвертированного индекса.
12. Для обеспечения высокой пропускной способности трафик чтения и записи разделен.
13. Популярный видеоконтент передается из CDN (в памяти)
14. Модель push CDN можно использовать для кэширования видео, загруженных пользователями со значительным количеством подписчиков.
15. Видеоконтент с умеренной потоковой передачей может передаваться с видеосервера напрямую (дисковый ввод-вывод)
16. Последовательное хеширование можно использовать для балансировки нагрузки на серверы кеша.
17. Кэширование может быть реализовано на нескольких уровнях для уменьшения задержки.
18. Можно использовать политику вытеснения кэша LRU
19. Энтропия или джиттер реализованы при истечении срока действия кеша, чтобы предотвратить массовый сбой
20. Видеофайлы распределяются в центры обработки данных ближе к клиенту, когда клиент начинает потоковую передачу.
21. Трафик должен иметь приоритет между кластером потокового видео (более высокий приоритет) и общим кластером для повышения надежности.
22. Видео можно рекомендовать клиенту на основе географии, истории просмотров (алгоритм KNN) и A/B-тестирования< /а> результаты
23. Видеофайл разбит на фрагменты для потоковой передачи и повышения отказоустойчивости.
24. Фрагменты видеофайла объединяются, когда клиент начинает потоковую передачу.
25. Фрагменты видео позволяют выполнять адаптивную потоковую передачу, переключаясь на фрагменты более низкого качества, если фрагменты высокого качества загружаются медленнее.
26. Разные протоколы потоковой передачи поддерживают разные кодировки видео и проигрыватели.
27. Видеоконтент передается по TCP через буферизацию
28. Смещение видео сохраняется на сервере для возобновления воспроизведения с любого клиентского устройства.
29. Разрешение видео при воспроизведении зависит от устройства клиента.
30. Видеофайл должен быть закодирован в совместимые битрейт (качество) и форматы для более плавной потоковой передачи и совместимости.
31. Счетчик лайков на видео может быть неточным для повышения производительности (транзакции выполняются через определенные промежутки времени)
32. Комментарии к видеоконтенту отображаются владельцу комментария путем получения данных от лидера (базы данных), в то время как другие пользователи могут получать данные от подписчиков с небольшой задержкой.
33. Сервисы могут быть предварительно масштабированы для чрезвычайно популярных каналов, поскольку автоматическое масштабирование может не соответствовать требованиям одновременно работающих клиентов.
34. Требования к автоматическому масштабированию можно предсказать путем машинного обучения шаблонов трафика.
35. Служба автомасштабирования должна иметь временной буфер из-за ожидаемых задержек в предоставлении ресурсов.
36. Полностью запеченные образы контейнеров (после подготовки не требуется выполнение дополнительных сценариев) сокращают время запуска служб.
37. Инфраструктуру можно предварительно прогреть перед пиковыми нагрузками, используя эталонные данные посредством нагрузочного тестирования.

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

Ссылки

• Cuong Do, Масштабируемость YouTube, Google Talks
• Архитектура Vitess, vitess.io

Также опубликовано здесь.

Избранное изображение источник.

н