В соответствии с документацией Spring Cloud Stream:
Когда существует несколько экземпляров потребителей, связанных с одним и тем же именем группы, тогда сообщения сбалансированы по нагрузке между этими экземплярами потребителей, так что каждое сообщение отправляетсяпроизводитель использует только один потребительский экземпляр в каждой группе.
Я хотел бы понять стратегию балансировки нагрузки, используемую в этом контексте.Кроме того, хотелось бы понять, как на балансировку нагрузки на потребителей влияет использование следующих свойств:
spring.cloud.stream.bindings.input.consumer.concurrency
spring.cloud.stream.<binder>.bindings.input.consumer.prefetch
В нашем случае связующим является RabbitMQ.
Наше потребительское приложениепросто проход и не имеет никакой существенной логики.Наша полезная нагрузка - текстовое сообщение размером ~ 2 КБ.Нагрузка, создаваемая для обработки потребителем, составляет 10 КБ.
Когда у нас есть следующие конфигурации и до 4 или 5 экземпляров работающих потребителей,
spring.cloud.stream.bindings.input.consumer.concurrency=10
spring.cloud.stream.rabbit.bindings.input.consumer.prefetch=5
Нагрузка кажетсяраспределяться равномерно, но когда мы начинаем увеличивать экземпляры за пределы 5, распределение становится не столь равномерным, т. е. один из этих экземпляров начинает получать больше нагрузки, в то время как другие экземпляры простаивают или просто не делят нагрузку одинаково.
Однако, если мы начнем уменьшать значения параллелизма и предварительной выборки, мы начнем видеть некоторое равномерное распределение среди экземпляров, то есть с указанными ниже свойствами и до 10 экземпляров мы наблюдаем равномерное распределение.
spring.cloud.stream.bindings.input.consumer.concurrency=2
spring.cloud.stream.rabbit.bindings.input.consumer.prefetch=1
Обладая свойствами instanceCount и instanceIndex, похоже, не дает желаемых результатов.
spring.cloud.stream.instanceCount
spring.cloud.stream.instanceIndex
Хотя мы понимаем, что эти свойства instanceCount и instanceIndex имеют больше смысла в многораздельной среде.Поскольку RabbitMQ не разделен естественным образом, мы, возможно, не увидим разницу.
Похоже, мы должны иметь возможность добавить собственную стратегию разделения в наших производителях, чтобы распределить нагрузку между очередями с RabbitMQ.Однако нам придется изменить нашу структуру полезной нагрузки, чтобы внедрить такую стратегию.
Но перед этим нам хотелось бы понять, что если бы существовал эффективный способ балансировки нагрузки, просто используя оптимальное значение в свойствах потребителя.