Принудительно получать сообщения об ошибках, когда включен режим постоянной доставки

Question

У меня есть RabbitMQ Server, где я извлекаю сообщения, используя Python-Pika. Проблема в том, что если у меня включен persistent delivery mode, и рабочие не смогут обработать сообщение. Вместо того, чтобы отпускать сообщение, он будет хранить его до тех пор, пока сообщение не будет сброшено до соединения RabbitMQ.

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

Это мой текущий код

if success: 
    ch.basic_ack(delivery_tag=method.delivery_tag) 
else: 
    syslog.syslog('Error (Callback) -- Failed to process payload: %s' % body) 

Идея заключается в том, что я никогда не хочу потерять сообщение, вместо этого я хочу, чтобы повторно опубликовано, а точнее возобновились, если это не удалось. Это всегда должно быть так, пока сообщение не будет успешно обработано рабочим. Обычно это происходит, когда один из рабочих не может открыть соединение с HTTP-сервером.

Answer 1

Я, наконец, понял, почему это происходит. Я не понимал, что этого недостаточно, чтобы просто признать, когда вы закончили с сообщением, но также пришлось отклонить любое сообщение, которое вы не могли обработать, используя channel.basic_reject. Это может показаться очевидным, но это не по умолчанию для AMQP.

В основном мы должны освободить сообщение, используя basic_reject с requeue, установленным на True. Важным фактором здесь является ключевое слово requeue, которое предотвращает отбрасывание сообщения и вместо этого снова ставит его в очередь, чтобы один из наших доступных работников мог его обработать.

if success: 
    # On Success - Mark message as processed. 
    ch.basic_ack(delivery_tag=method.delivery_tag) 
else: 
    # Else - Mark message as rejected and move it back to the queue. 
    ch.basic_reject(delivery_tag=method.delivery_tag, requeue=True) 

Я нашел некоторые действительно полезную информацию в this статье, и есть более технические детали по reject ключевым словам в this блоге.