Поддержание видео производительности сайта

Question

Я настраиваю веб-сайт для воспроизведения видео (например, Youtube ). Моя техническая задача - обслуживать много хитов и при этом поддерживать производительность.

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

Другой сервер переднего плана хэширует request video ID, чтобы выяснить, на каком сервере находится видео, и затем просит браузер клиента перенаправить на определенный сервер.

Мое решение простое, и я хочу знать, есть ли у кого-нибудь еще идеи или технические соображения относительно моего решения?

---

Обратите внимание: я хочу настроить сайт для локальной работы (и не полагаться на таких провайдеров, как Alakami), так как контент предназначен для местных учеников из моей школы. По сути, это будет решение для «внутренней сети».

Answer 1

Попробуйте Amazon CloudFront (CDN), если ваши пользователи распределены по всему миру. Если ваши пользователи локализованы (США / Европа), вы можете использовать S3.

Кроме того, вы также можете попробовать использовать Nginx (веб-сервер), который чрезвычайно эффективен при обслуживании больших файлов.

Таким образом, вам не нужно иметь дело с ненужной архитектурной сложностью в вашем приложении.

Answer 2

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

Обратите внимание, что серверы хранения (RAID-массивы, SAN) могут доставлять данные с очень высокой скоростью, поэтому вы часто можете использовать одну систему хранения для нескольких видеосерверов (т.е. одну систему хранения на N видеосерверов и 1 балансировщик нагрузки (или два, если вы хотите аварийного переключения)).

Хорошим решением здесь является использование команды «redirect» в протоколе:

1. Клиент запрашивает балансировщик нагрузки (LB) для видео
2. LB сообщает клиенту, какой видеосервер (VS) использовать. Это просто «найти VS с наименьшим количеством открытых каналов».
3. Клиент подключается напрямую к VS (чтобы избежать всех накладных расходов)
4. VS сообщает LB текущее количество открытых каналов (не используйте инкрементальный подход здесь, чтобы избежать проблем с синхронизацией)
5. VS начинает потоковую передачу данных клиенту
6. Когда клиент отключается, VS сообщает LB о новом количестве каналов

[РЕДАКТИРОВАТЬ] Основной причиной, по которой клиенты подключаются напрямую к видеосерверам, является пропускная способность сети. Если все VS отправляют свои данные в LB, который передает их клиентам, вы ограничиваете скорость единственной (или двойной) сетевой карты LB. Если у вас 5 VS, вы можете получить пятикратную пропускную способность при прямом подключении. Кроме того, вы можете легко масштабировать свою систему, когда большее количество пользователей «забивают» ее, просто добавив другой видеосервер, подключив его к магистрали и добавив одну запись в список на LB.

Answer 3

Одним из решений для очень высокой производительности является использование службы распространения данных, такой как Akamai . Они предлагают серверное пространство по всему миру, и они уже решили проблему производительности. Кроме того, поскольку у них есть дата-центры по всему миру, ваши данные не должны перемещаться слишком далеко, что хорошо для Интернета и для вас (поскольку Akamai может взимать более низкую плату за один и тот же объем данных).

Answer 4

Вы размещаете это на Windows в IIS7? если это так, у них есть модуль для IIS, позволяющий регулировать видео, чтобы он не передавался в потоковом режиме быстрее, чем пользователь может его просмотреть.