#java #amazon-web-services #spring-boot #rabbitmq #amazon-mq
Вопрос:
Я использую управляемый кластер RabbitMQ через AWS Amazon-MQ. Если потребители быстро заканчивают свою работу, то все работает нормально. Однако, в зависимости от нескольких сценариев, некоторым потребителям требуется более 30 минут для завершения обработки. В этом случае RabbitMQ удаляет потребителя и снова делает те же сообщения видимыми в очереди. Из-за этого другой потребитель берет его и начинает обрабатывать. Это происходит в цикле. Поэтому та же транзакция выполняется снова, и я также теряю потребителя. Я не использую никакихРежим подтверждения, поэтому я считаю, что по умолчанию он АВТОМАТИЧЕСКИЙ и имеет ограничение на 30 минут. Есть ли какой-либо способ увеличить время ожидания подтверждения доставки для автоматического режима? Или, пожалуйста, дайте мне знать, если у кого-нибудь есть какие-либо другие решения для этого.
Комментарии:
1. На данный момент, похоже, нет способа изменить конфигурацию (rabbitmq.conf) управляемого экземпляра aws rabbitmq. Я пробовал rabbitmqadmin. Существует еще один инструмент под названием rabbitmqctl, но я просмотрел документацию, и, похоже, там тоже нет возможности изменить конфигурацию. Есть ли у вас возможность настроить rabbitmq на экземпляре EC2? Затем вы можете напрямую изменить файл rabbitmq.conf… # 30 минут в миллисекундах consumer_timeout = 1800000
2. Ваш другой вариант-сразу же подтвердить сообщения, а затем обработать их…но проблема в том, что происходит, если сообщение обрабатывается неправильно? Это больше не будет возмущать AMQ
3. Спасибо! Это очень полезно, я обращусь в службу поддержки AWS и посмотрю, есть ли у них возможность изменить это.
4. Надеюсь, вы получите ответ, и если вы это сделаете, пожалуйста, сообщите нам об этом здесь :). Удачи
Ответ №1:
Это ответ службы поддержки AWS.
Насколько я понимаю, я вижу, что на вашу рабочую нагрузку в настоящее время влияет параметр consumer_timeout, который был введен в версии v3.8.15. Из-за этого у нас было несколько обращений, к сожалению, сервисная команда подтвердила, что, хотя они могут вручную редактировать файл rabbitmq.conf, он будет перезаписан при следующей перезагрузке или отработке отказа и, следовательно, не является рекомендуемым решением. Это также будет означать, что все исправления безопасности на брокерах, где применяется изменение вручную, должны быть приостановлены. В настоящее время служба не поддерживает пользовательские пользовательские конфигурации для RabbitMQ из этого файла конфигурации, но подтвердила, что они планируют решить эту проблему в будущем, однако не может сообщить, когда это будет доступно.
Из github RabbitMQ, похоже, это было добавлено для очередей кворума в версии v3.8.15 (https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.15 ), но, похоже, распространяется на всех потребителей (https://github.com/rabbitmq/rabbitmq-server/pull/2990 ).
К сожалению, RabbitMQ сам по себе не поддерживает понижение рейтинга (https://www.rabbitmq.com/upgrade.html ) Таким образом, рекомендуемый обходной путь и самое безопасное действие для команды службы на данный момент-создать нового брокера на более старой версии (3.8.11) и установить автоматическое обновление младшей версии в значение false, чтобы оно не обновлялось. Затем экспортируйте конфигурацию из существующего экземпляра RabbitMQ, импортируйте ее в новый экземпляр и используйте этот экземпляр в дальнейшем.