Я был удивлен, прочитав в документации rabbitmq, что очень большие размеры очереди отрицательно сказываются на ее производительности. У меня есть диспетчер заданий, который потенциально может ставить в очередь более 30 тыс. Сообщений для потребителей заданий и замечал низкую производительность даже после увеличения числа потребителей. Затем я написал код со стороны публикации, чтобы проверить размер очереди, и, если она слишком велика, я сплю некоторое время, пока размер очереди не станет меньше.
Я обнаружил, что это улучшает производительность, но сомневаюсь в логике этого. Просто кажется неприятным, что издатель должен знать о таких деталях системы очередей, что он сам должен ограничивать скорость, это как бы нарушает абстракцию, не так ли? Это нормально для всех систем очередей сообщений? Есть ли альтернативные решения с RabbitMQ или другими библиотеками?





Вы правы, что вашему издателю не следует беспокоиться о размере очереди. Однако программист должен:
Убедитесь, что у вас достаточно оборудования и / или горизонтального масштаба вашего кластера для обработки объема сообщений. 30К сообщений не должно быть сложной задачей для одного брокера, если они имеют соответствующий размер.
Убедитесь, что размер ваших сообщений не превышает 100 КБ. Если они содержат большие двоичные объекты, вы захотите сохранить эти объекты в хранилище данных и опубликовать только указатель на эти ресурсы в своем сообщении.
RabbitMQ имеет функции управления потоком для работы с чрезмерно усердными издателями. Я не уверен, каковы ваши настройки, но вы можете настроить их, чтобы вызвать это. Подробнее: https://www.rabbitmq.com/flow-control.html
Имейте в виду, что идеальный размер очереди заданий равен нулю, поэтому ваша система должна быть спроектирована таким образом, чтобы длина очереди была как можно меньше. Это означает, что сообщения обрабатываются примерно с той же скоростью, с которой они создаются.