Из-за жестких временных ограничений и хороших возможностей распараллеливания мой серверный сервер должен обрабатывать один запрос в нескольких независимых рабочих процессах. Для этого я предоставил набор n рабочих процессов, которые взаимодействуют с основным процессом через многопроцессорные очереди. Основной поток помещает данные во входную очередь, и каждый рабочий поток берет из него элемент и обрабатывает его.
Для пояснения, пример : предположим, это система, которая проверяет, какие числа в [0, 100) делятся на x. Пользователь отправляет число x в REST API. Таким образом, основной процесс помещает кортежи (i, x) for i in range(100) в очередь. Каждый рабочий процесс затем выводит один кортеж из очереди и помещает (i, i % n == 0) в очередь результатов. Как только основной процесс вернет 100 результатов, он ответит пользователю.
Хотя это нормально работает в автономной системе, это создает проблемы, когда я помещаю его за сервер gunicorn, а именно информацию в очередях теряется и основной процесс зависает. Мне нужен gunicorn, потому что я хочу сделать этот сервис доступным через REST API в Интернете.
(1) Есть ли возможность сделать его совместимым с gunicorn?
Согласно моим предыдущим исследованиям, gunicorn несовместим с модулем multiprocessing Python. Следовательно, (2) есть ли альтернативы вышеописанному подходу в этом случае?
Например, в качестве альтернативы я подумал о множестве независимых процессов обслуживания, которые не порождаются в приложении Python, но довольно автономны. Однако я не могу придумать простой и эффективной возможности реализовать это. Если бы я реализовал другой REST API для этих рабочих процессов, я бы потерял много времени на отправку сообщений через сетевой стек. Таким образом, мне нужен более низкоуровневый подход, такой как каналы или разделяемая память. (3) У вас есть предложения для меня?