Поведение rabbitmq flow-control при зависании одного клиента из многих

Я пытаюсь понять, как управление потоком Rabbitmq для каждого соединения работает с несколькими потребителями. В частности, что произойдет, если один потребитель повесится? Будет ли задействовано управление потоком и как это повлияет на остальных потребителей? Будет ли поведение зависеть от того, являются ли очереди устойчивыми или автоматически удаляемыми?

Спасибо.


person C R    schedule 30.01.2014    source источник
comment
Пожалуйста, опишите, что вы подразумеваете под управлением потоком, так как это может иметь несколько значений в RabbitMQ в зависимости от вашей настройки.   -  person theMayer    schedule 01.02.2014
comment
Я имею в виду за соединение. Я изменил вопрос и добавил ссылку на соответствующую страницу документации rabbitmq.   -  person C R    schedule 01.02.2014


Ответы (2)


Rabbit MQ использует «Управление кредитным потоком».

По сути, всякий раз, когда сообщение получено на канале, кредит вычитается. Кредит начинается с уровня по умолчанию, например. 200, а когда он опускается ниже 0, соединения блокируются. После того, как определенное количество сообщений использовано и подтверждено ACK, кредит увеличивается на определенную сумму.

Вы можете прочитать больше об этом здесь:

http://videlalvaro.github.io/2013/09/rabbitmq-internals-credit-flow-for-erlang-processes.html

person Rene Wooller    schedule 23.02.2015

Per-connection flow control описывает, что происходит, когда издатель (или группа издателей) отправляет сообщения в очереди быстрее, чем очереди обрабатываются. Это функция безопасности, поскольку RabbitMQ становится нестабильным в какой-то момент, когда очередь заполняется без ограничений. Из документации это автоматически:

RabbitMQ будет блокировать соединения, которые публикуются слишком быстро для очередей. Настройка не требуется.

К сожалению, документация не очень конкретна в отношении того, когда и как реализуется это управление потоком, кроме как «несколько раз в секунду». Таким образом, если один потребитель застревает, пока другие потребители могут не отставать, управление потоком не должно запускаться.

person theMayer    schedule 01.02.2014
comment
Я не согласен - я наблюдал, как обмен разветвляется на 5 отдельных очередей. 4 очереди не отставали от скорости публикации, но одна из них застряла. После того, как он достиг примерно 4 млн, частота публикаций периодически падала вдвое — не было никаких других ошибок, которые могли бы предложить что-либо, кроме RMQ. Я могу списать это только на кредитный поток. - person Rene Wooller; 24.02.2015
comment
@ReneWooller Можете ли вы уточнить, с чем вы не согласны в данном случае? Читая ваш ответ ниже, это звучит как разработка того, что я уже изложил. Интересно, но не обязательно несогласие. - person theMayer; 24.02.2015
comment
В частности, это утверждение Итак, если один потребитель застревает, пока другие потребители могут не отставать, управление потоком не должно запускаться. Если один потребитель застревает, а очередь, которую он вытаскивает, становится невыполненной, это активирует управление потоком. Я только что понял, что вы можете иметь в виду группу потребителей, выходящих из одной и той же очереди - если это то, что вы имели в виду, я не согласен. - person Rene Wooller; 25.02.2015
comment
Ну, это то, что я имел в виду - вопрос был неясен в этом отношении, и я должен был попросить разъяснений. - person theMayer; 25.02.2015