Нерест рабочих в Python

Question

Я работаю над фрагментом кода, который сможет работать с несколькими веб-API (аппаратное обеспечение с API-интерфейсами, которые сообщают о состоянии компьютера), не блокируя, когда один ожидает от другого, чтобы дождаться ответа, как только ответиз одного прибывает, он будет выпущен на веб-сокет.Одно из требований - не убивать API, поэтому нажимайте их, скажем, раз в 5 секунд, пока работает основной процесс.

Важная часть, с которой я борюсь, - это как подойти к ней.Что я сделал к этому моменту, так это то, что основной процесс порождает отдельные потоки для разных API, и этот поток обрабатывает API, отправляя ответ на веб-сокет time.sleep(5) и повторяя его.Основной процесс отвечает за запуск новых «рабочих» и уничтожение тех, кто больше не нужен, а также за перезапуск тех, которые должны работать, но не являются, например, исключением.Я понятия не имею, является ли здесь многопоточность - скажем, я стремлюсь «пролистать» через 300 API.

Является ли порождение долгоживущих работников правильным способом для достижения этой цели?Должны ли это быть процессы?Должен ли я иметь координату основного процесса, выполняющую недолговечные потоки, которые будут выполнять вызов API и умирать и делать это каждые 5 секунд для API (что, кажется, гораздо хуже поддерживать)?Если последний вариант, то как обрабатывать случаи, когда получение ответа занимает более 5 секунд?

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

Может ли кто-нибудь направить меня в правильном направлении?

Answer 1

Позвольте мне перефразировать это и сказать, прав ли я:

Я хочу часто посещать ~ 300 API, чтобы каждый срабатывал примерно каждые 5 секунд. Как мне подойти к этому и какое управление работником / процессом я должен использовать?

Есть два основных подхода:

1. Создать поток для каждого API, который в данный момент просматривается (т. Е. Часто затрагивается) - возможно только в том случае, если в любой момент времени просматривается только подмножество вашего общего числа возможных API.
2. Настройка рабочего пула, в котором все работники используют одну и ту же очередь и имеют процесс управления, который заполняет очередь в соответствии с временными ограничениями - вероятно, лучше, когда вы всегда хотите просмотреть все возможные API.

Редактировать после вашего первого комментария:

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

Чтобы избежать слишком частого обращения к API, вы можете добавить целевые метки времени вместе с адресом API в очередь (например, в виде кортежа) и попросить работника подождать, пока это время не будет достигнуто, прежде чем запускать запрос к этому API. Это замедлит потребление всей вашей очереди, но будет поддерживать минимальную задержку между попаданиями в один и тот же API. Если вы решите это сделать, вам просто нужно убедиться, что (а) запросы API всегда отвечают в разумные сроки, и (б) все адреса API добавляются в очередь в циклическом порядке.