Informat RabbitMQ Multi-threaded Consumption Configuration and Implementation Guide
1. Overview
This document provides complete configuration, code implementation, and best practices for RabbitMQ multi-threaded consumption in the Informat system, applicable to scenarios requiring improved message processing throughput. The core goal is to achieve multi-threaded concurrent consumption through SpringBoot container thread pool management while ensuring the security and reliability of message processing.
2. Core Principles
RabbitMQ multi-threaded consumption relies on the SimpleMessageListenerContainer (default listening container) provided by SpringBoot, implementing concurrency through the following core configurations:
- Minimum concurrent consumers (
concurrency): Fixed base consumption thread count - Maximum concurrent consumers (
max-concurrency): Maximum thread count for dynamic scaling - Prefetch message count (
prefetch): Controls the maximum number of messages prefetched by each consumer to avoid uneven message distribution - Manual ACK (
acknowledge-mode: manual): Compatible with Informat's custom ACK logic, ensuring message reliability
3. Detailed Configuration
3.1 application.yml Configuration
Complete the RabbitMQ connection information and core multi-threaded consumption parameters as follows:
yaml
spring:
rabbitmq:
# Basic connection configuration
port: 5672
host: 127.0.0.1
username: admin
password: password
virtual-host: /
nickname: Informat-Next
# Publisher confirmation configuration (optional, ensures producer-side reliability)
publisher-confirm-type: correlated
publisher-returns: true
template:
mandatory: true
# Consumer listener container configuration (multi-threaded core)
listener:
simple:
acknowledge-mode: manual # Manual ACK, compatible with Informat business logic
concurrency: 5 # Minimum concurrent consumption thread count (adjust according to CPU cores)
max-concurrency: 10 # Maximum concurrent consumption thread count (dynamic scaling)
prefetch: 10 # Number of messages prefetched by each consumer (avoids message accumulation)
default-requeue-rejected: false # Failed messages do not return to queue (adjust according to business)
retry:
enabled: false # Disable Spring default retry (Informat business handles failure logic independently)
