ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Если этот пост не относится к c этому сайту, пожалуйста, порекомендуйте сайт, где этот пост был бы уместен.
В Ubuntu 18.04, в bash, я пишу сеть -поточное приложение, для которого требуется несколько серверов. Он получает файлы по сети и обрабатывает их, в конечном итоге выполняя вызов API, который завершает обработку и записывает результаты в базу данных для последующего извлечения и отчетности.
Пока что я написал приложение, используя беспотоковое программирование модели и концепции. Это означает, что файлы обрабатываются по одному в реальном времени. Это отлично работает, если нет внезапного всплеска файлов и / или невыполненных файлов для обработки. Основная bottle шейка заключалась в том, что я последовательно отправляю файлы в API один за другим, ожидая, пока вся операция не будет выполнена для одного файла и API вернет результаты. API имеет ограничение скорости 8 вызовов в секунду. Но поскольку каждый вызов занимает от 0,75 до 1 секунды, моя программа ожидает завершения операции и обрабатывает через API только 1 файл в секунду. Короче говоря, мне не нужно было беспокоиться о планировании вызовов API, потому что я едва мог выполнять один вызов в секунду.
Поскольку есть возможность обрабатывать 8 файлов в секунду, и мне нужно больше скорости, я был преобразование моего однопоточного последовательного приложения в параллельное масштабируемое многопоточное приложение. Эта новая версия может порождать достаточно потоков для отправки 8 файлов в секунду в REST API и многое другое. Так что теперь у меня противоположная проблема. Я отправляю слишком много запросов в секунду в REST API, и мне грозят штрафы и т. Д. c. В конечном счете, когда мой трафик c станет выше, я обновлю подписку на API и буду получать больше вызовов в секунду, но эта текущая дилемма заставила меня задуматься о том, как планировать вызовы API с разными потоками.
Цель этого поста - обсудить идею о том, как запланировать эти вызовы REST API для различных потоков. В частности, я хочу обсудить, как координировать время и использование API, сохраняя при этом эффективность и не перегружая API. Короче говоря, я хочу координировать группу потоков, чтобы API правильно использовался. Не слишком быстро и не слишком медленно.
Независимо от моего приложения, эта идея может быть полезна в ряде в целом похожих сценариев ios.
Моя идея состоит в том, чтобы создать «воздушный поток». c controller "(" AT C "), чтобы потоки приложения имели централизованные полномочия по времени для проверки, когда они готовы отправить файлы в REST API. AT C будет знать, сколько временных интервалов / вызовов за период времени (в данном случае вызовов в секунду) API может запланировать. AT C будет ожидать, что потоки запросят временной интервал («код запуска»), который предоставит им временной интервал в будущем для выполнения их вызова API. AT C примет решение на основе расписания других кодов запуска, которые он уже выдал.
В моем случае с начала загрузки файла в API может потребоваться 0,75 для 1 секунда для завершения обработки и получения ответа от API. Это не влияет на количество новых вызовов API, которые могут быть выполнены. Это просто учет того, как долго потоки будут ждать после вызова API. Это может не иметь отношения к этому общему обсуждению.
Очевидно, что каждому потоку придется выполнять некоторую обработку ошибок. Если истекло время ожидания API или возникла ошибка, поток должен был бы обработать это и вернуться в соответствие с AT C - если необходимо - и запросить новый код запуска. Может быть, он должен сообщить об ошибке AT C для централизованного ведения журнала?
В ситуациях, когда обработка файлов требует увеличения скорости более 8 файлов в секунду, будет невыполнение расписания, когда потоки должны ждать своей очереди, поскольку назначается AT C.
Вот некоторые другие соображения:
Функция
AT C будет легким демоном, который выполняет следующие действия: - прослушивает какой-либо порт TCP - получает токен безопасности запроса (?), Идентификатор потока, приоритет - проверяет подлинность запроса (?) - проверяет расписание - резервирует следующий доступный временной интервал - возвращает токен безопасности кода запуска (?), текущее время, смещение времени запуска к текущему времени, URL-адрес и токен аутентификации для API - удаленные просроченные коды запуска
AT C будет необходимо следующее: - знать, на каком порту он должен работать - знать, сколько слотов за период времени он был установлен для расписания (например, 8 в секунду) - иметь сверхбыстрый доступ для чтения / записи к расписанию (ассоциативный array?) - чтобы узнать URL-адрес и соответствующий токен аутентификации для используемого потока - возможно, чтобы узнать несколько URL-адресов и токенов аутентификации для балансировки нагрузки
Вот еще что нужно учитывать:
Безопасность Как обеспечить безопасность AT C при сохранении высокой производительности? Безопасность на уровне сети (например, межсетевые экраны, разрешающие только IP-адреса серверов обработки файлов?) Токены аутентификации или логины и пароли?
Производительность Каковы будут требования для этого AT C сервер? Будет ли это обременять ЦП и память?
Время Как часто может потребоваться вызов NTP? Сервером AT C? Серверы, которые вызывают API?
Масштабируемость Возможность предоставления разных URL-адресов и токенов аутентификации позволит AT C балансировать нагрузку с разными поставщиками API.
Многопоточность самого AT C Должен ли AT C создавать потоки, чтобы иметь возможность обрабатывать каждый новый запрос? Как веб-сервер обрабатывает запросы? Как разные темы будут иметь общий график? В непоточной среде AT C, возможно, сохранит в памяти ассоциативный массив, чтобы поддерживать производительность на максимально высоком уровне. Каким образом различные потоки AT C будут иметь доступ к одному и тому же расписанию?
Итак, вот мой вопрос. Это существует? Если нет, то каковы некоторые передовые практики при попытке создать вышеупомянутое?
Похоже на сетевой сервис beanstalkd, за исключением того, что он предоставляет только разрешения / планирование и очень зависит от времени.