Как вы заметили, ваш процесс блокируется при запуске обратного вызова.Есть несколько способов справиться с этим в зависимости от того, что делает ваш обратный вызов.
Если ваш обратный вызов связан с вводом-выводом (при выполнении большого количества сетевых или дисковых операций ввода-вывода), вы можете использовать либо потоки, либо решение на основе гринлета, напримеркак gevent , eventlet или теплица .Имейте в виду, однако, что Python ограничен GIL (Global Interpreter Lock), что означает, что только один кусок кода Python когда-либо выполняется в одном процессе Python.Это означает, что если вы выполняете много вычислений с использованием кода Python, эти решения, скорее всего, будут не намного быстрее, чем у вас уже есть.
Другой вариант - реализовать вашего потребителя как несколько процессов с использованием многопроцессорной обработки ..Я обнаружил, что многопроцессорная обработка очень полезна при параллельной работе.Вы можете реализовать это либо с помощью Queue , с родительским процессом, который будет потребителем, и отрабатывать работу для своих детей, либо просто запустив несколько процессов, каждый из которых потребляет самостоятельно.Я бы посоветовал, если ваше приложение не является слишком параллельным (тысячи рабочих), просто запустить несколько рабочих, каждый из которых потребляет из своего собственного соединения.Таким образом, вы можете использовать функцию подтверждения AMQP, поэтому, если потребитель умирает во время обработки задачи, сообщение автоматически отправляется обратно в очередь и принимается другим работником, а не просто теряет запрос.
Последний вариант, если вы контролируете производителя и он также написан на Python, - это использовать библиотеку задач, такую как celery , чтобы абстрагировать работу задачи / очереди для вас.Я использовал сельдерей в нескольких крупных проектах и нашел, что он очень хорошо написан.Он также будет обрабатывать многочисленные потребительские проблемы для вас с соответствующей конфигурацией.