1 Message Overload

Assuming a RabbitMQ server has tens of thousands of unprocessed messages, opening a single consumer can result in a huge amount of messages being pushed to the server in a single instant, but we cannot process that much data from a single client.

For example, a single Pro generates hundreds of pieces of data per minute, while a single Con may only process 60 pieces per minute. In this case, Pro-Con is unbalanced. Generally, Pro cannot limit traffic, so Con needs to take some measures to limit traffic. Otherwise, if the maximum load is exceeded, Con’s performance may deteriorate, and the server may stall or even crash.

Therefore, we need Con limiting.

2 Con Current limiting mechanism

RabbitMQ provides a quality of service (qos) function that does not automatically acknowledge messages and does not consume new messages until a certain number of messages have been acknowledged (via a con-based or channel-based qos).

Cannot set autoAck (autoAck = false) If the message is not acknowledged, it will not reach Con

Stream limiting setting API

basicQos

  • QoS

Request a specific setting of Quality of Service. These Settings impose data that the server will need to confirm before limiting the number of messages sent for consumers. Therefore, they provide a means of consumer-initiated traffic control.

void BasicQos(uint prefetchSize, ushort prefetchCount, bool global);
Copy the code
  • PrefetchSize: Limit on the size of a single message. Con is usually set to 0, indicating no limit
  • PrefetchCount: The maximum number of messages that can be processed at one time
  • Global: Whether to apply the above setting true to the channel level or false to the Con level

PrefetchSize and global are not implemented by RabbitMQ, so prefetchCount takes effect with autoAck=false, so it must be ACK manually.

void basicAck(Integer deliveryTag,boolean multiple)
Copy the code

Calling this method actively sends a reply back to the Broker saying I’m done with the message and you can send me the next one. The multiple parameter indicates whether to batch sign in, which is set to false since we are processing one message at a time.

3 Code practice

  • Custom Con

  • Con

  • Pro

  • Start Con and view the control console

  • Start Pro, start sending messages, and Con receives messages

  • Implement flow limiting where only one message is processed and the rest is waiting
  • Now, let’s turn on ACK reply processing

  • Restart Con and find that the remaining 2 messages were also sent and received!
  • We commented out the manual ACK method before, and then started the consumer side and the production side. At that time, Con only printed one message, this is because we set the manual sign in and set only one message at a time. When we did not send back the ACK reply, The Broker considers that Con has not processed the message and will not send a new message due to the flow limiting mechanism, so Con prints only one message at that time