Я использую последнюю версию библиотеки pika (0.9.9+) для rabbitmq. Я использую rabbitmq и pika следующим образом:
- У меня как рабочих есть длительные задачи (около 5 минут). Эти задачи берут свои запросы от rabbitmq. Запросы поступают очень редко, т.е. между запросами бывает длительное время простоя.
- Проблема, с которой я столкнулся ранее, связана с незанятыми соединениями (закрытие соединений из-за незанятых соединений). Итак, я включил сердцебиение в пике.
- Теперь проблема с выбором сердцебиения. Кажется, что Pika - это однопоточная библиотека, в которой прием и подтверждение пульса происходит в промежутках между запросами.
- Таким образом, если интервал пульса установлен меньше времени, которое функция обратного вызова использует для выполнения своих длительных вычислений, сервер не получает никаких подтверждений пульса и закрывает соединение.
- Итак, я предполагаю, что минимальный интервал пульса должен быть максимальным временем вычисления функции обратного вызова в блокирующем соединении.
Какое значение пульса для amazon ec2 может быть хорошим, чтобы предотвратить закрытие незанятых соединений?
Кроме того, некоторые предлагают использовать rabbitmq keepalive (или libkeepalive) для поддержки TCP-соединений. Я думаю, что управление тактовыми сигналами на уровне tcp намного лучше, потому что приложение не должно управлять ими. Верно ли это? Является ли поддержка активности хорошим методом по сравнению с сердцебиением RMQ?
Я видел, что некоторые предлагают использовать несколько потоков и очереди для длительных задач. Но разве это единственный вариант для длительных задач? Очень досадно, что для этого сценария необходимо использовать другую очередь.
Заранее спасибо. Думаю, я подробно описал проблему. Дайте мне знать, если я могу предоставить более подробную информацию.