Я ищу совета по архитектуре. У меня есть клиент, для которого я создал веб-сайт, который позволяет пользователям удаленно просматривать свои веб-камеры.
Текущий поток данных выглядит следующим образом:
Пользователь открывает страницу для просмотра изображения с веб-камеры. Скрипт Javascript опрашивает URL-адрес на сервере (с добавлением уникальной отметки времени) каждые 1000 мс.
Для пользователя ftp камеры разрешено FTP-соединение. Веб-камера открывает ftp-соединение с сервером. Веб-камера начинает фотографировать. Веб-камера отправляет фото на ftp-сервер.
По запросу URL изображения: сервер читает последнее изображение на жестком диске, загруженное через ftp для камеры. Сервер удалил все старые изображения с сервера.
На данный момент это нормально работает для небольшого количества пользователей / камер (около 10 пользователей и примерно такое же количество камер), но мы начинаем беспокоиться о масштабируемости этого подхода.
Мой первоначальный план заключался в том, чтобы вместо чтения файлов с сервера веб-сервер открывал ftp-соединение с веб-сервером и считывал последние изображения прямо оттуда, что означало, что мы могли довольно легко масштабировать по горизонтали. Но время установления ftp-соединения было слишком медленным (в основном из-за того, что PHP не может поддерживать ftp-соединения), поэтому мы отказались от этого подхода и сразу приступили к чтению с жесткого диска.
Поставщик прошивки для камер заявляет, что они могут создать http-клиент, который вместо использования ftp для загрузки изображения может отправить изображение на веб-сервер. Мне это кажется достаточно правдоподобным, но я ищу совета по архитектуре.
Моя текущая мысль - это простой стек Nginx / PHP / Redis.
Веб-камера отправляет запросы на публикацию последнего изображения в Nginx / PHP, и последнее изображение для этой камеры сохраняется в Redis.
Затем клиенты могут получить последний образ из Redis, что должно быть очень быстрым, поскольку изображения всегда будут храниться в памяти.
Тогда поток данных станет:
Пользователь открывает страницу для просмотра изображения с веб-камеры. Скрипт Javascript опрашивает URL-адрес на сервере (с добавлением уникальной временной метки) каждые 1000 мс.
Камере отправляется HTTP-запрос на отправку изображений по указанному URL-адресу. Веб-камера начинает делать фотографии. Веб-камера отправляет почтовые запросы на сервер так быстро, как только может
При запросе URL-адреса изображения: сервер считывает последнее изображение с сервера redis. Сервер сообщает redis об удалении более позднего изображения.
Мои вопросы:
заранее спасибо
Алан
Есть ли большие накладные расходы при передаче изображений через HTTP вместо FTP?
На самом деле, нет. HTTP легче ускорить и кэшировать, чем FTP.
Есть ли простой способ подсчитать, сколько потенциальных камер мы могли бы транслировать одновременно?
Один поток MPEG4 с разрешением 1080p составляет около 10 Мбит. Это приблизительная цифра. Вы должны иметь возможность масштабировать это до вашего фактического разрешения.
Есть ли способ предотвратить потенциальную загрузку наших серверов в DOS из-за запросов веб-камеры?
Уменьшить масштаб. Есть хороший прокси Node.js MJPEG Я использовал в прошлом, который масштабируется лучше, чем встроенный видеосервер камеры.
Redis - хорошее решение этой проблемы?
Наверное, не хуже любого другого. YMMV. Проведите небольшое тестирование.
Стоит ли отказаться от комбинации PHP / Nginx и перейти к чему-то другому?
Придерживайтесь того, что вам удобно.
Действительно ли это предлагаемое решение хорошо?
Звучит правдоподобно, в ожидании некоторых проверок концепции и бенчмаркинга
Не приведет ли добавление HTTPS в микс к слишком медленной публикации изображения?
Возможно, немного, но, вероятно, не в значительной степени. Опять же, вам нужно будет провести некоторое тестирование. Вероятно, вам удастся использовать отдельный обратный прокси-сервер для завершения SSL-соединений и, таким образом, иметь возможность использовать HTTPS для доступа к изображениям, но загрузка не выполняется через HTTPS (если вы этого хотите).
Есть также некоторые Карты ускорения HTTPS можно получить для реальных серверов.