Наиболее подходящий дизайн связи узел-сервер

Question

Я борюсь с разработкой части моего проекта.Идея состоит в том, что N узлов (каждый с одной камерой) будут непрерывно отправлять кадры на сервер для обнаружения объекта, а затем сервер будет повторно посылать ответ каждому узлу с некоторой информацией.

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

Как и в Python, параллельные потоки не доступны, я рассматриваю несколько подходов (при условии, что у меня естьЦП, который способен обрабатывать N * 2 потоков параллельно:

1) Сервер будет порождать два процесса (взаимодействующих друг с другом) для каждого узла (один для получения кадров и один для обнаружения объектов).(эти процессы будут выполняться независимо от основного процесса)

2) Сервер будет однопоточным и асинхронным.Каждый полученный кадр будет передан в пул процессов для обнаружения.

3) Сервер будет создавать поток для каждого узла (один поток будет обрабатывать принимаемые кадры от одного узла).Каждый полученный кадр будет передан в пул процессов для обнаружения объекта.

4) Сервер будет создавать поток для каждого узла и два отдельных потока в этом потоке, один для получения и один для обнаружения объекта

Какой подход кажется наиболее подходящим?Вы бы предложили что-то другое?

Answer 1

Мне нравятся архитектурные проблемы, вот что я хотел бы сделать, если бы мне пришлось делать этот проект. Workflow:

1. Узел отправит запрос на сервер, включая фреймы и узел ID
2. На основе идентификатора узла и фреймов Сервер создаст задание в очереди, используя redis в памяти, чтобы отслеживать задания, отправленные узлами, а также сохранять каждый запрос в БД
3. Сервер будет обрабатывать каждое задание, запуская работника на сервере, который будет извлекать и обрабатывать каждое задание из очередей переадресации.
4. Обновить запись о задании. По завершении задание будет помечено как выполненное, и результат будет сохранен.
5. Узел может позвонить на сервер, чтобы узнать состояние каждого задания, опубликованного узлом.

Вам необходимо создать интерфейс REST API на сервере, чтобы опубликовать задание с узла, сохранить этот запрос в БД и создать задание на основе этого запроса, а также отправить его в очередь повторного выполнения. Рабочий автоматически извлекает задания из очередей повторного выполнения и обновляет запись в БД на основе результатов обработки.

Вам необходимо следующее на стороне сервера :
- REST API
- Очередь Redis (RQ) Ссылка
- сервер БД

Используя эту архитектуру, вы можете легко вернуть облегченный результат немедленно клиенту и сохранить все задания в обработке. Архитектура RESTful - это широко используемая архитектура, но для трудоемких работ мы используем процессоры очередей, и клиент отправляет нам запрос на проверку статуса всех работ, отправленных на сервер. Если вам нужно, я могу нарисовать архитектуру, включая гораздо больше деталей.

Вкратце: если у вас есть клиент-серверная архитектура, используйте API REST для связи и отправки каждого запроса в хранилище очереди в памяти, если запрос, отправленный клиентом, занимает много времени и имеет многошаговые задания сделать. А с помощью этой архитектуры вы можете публиковать любое количество заданий, а также нескольких работников, балансировщиков нагрузки для производительности.