4 rabbitmq Advanced Features

RabbitMQ mainly in the following advanced features

• Delivery reliability (100% delivery success)

• Idempotence (resolve duplicate consumption)

• confirm the mechanism, return mechanism

• Custom consumers

• Ack message queue and return

• Message limiting

• TTL news

• Dead Letter Queue

100% successful delivery (delivery reliability)

Reliability of the delivery end of the production

• To ensure that the message was successfully sent
• MQ nodes successfully received protection
• MQ sender receives an Ack
• Improve the compensation mechanism for message

solution

• Method a: message storage, message status flag
• Method two: the message delivery delay, the second confirmation, correction check

Method 1: a message storage, a timing compensation task

biz/MsgDB -> sender -> mq broker -> confirm Listener -> MsgDB

schedule -> MsgDB -> retry sender -> retry count -> MsgDB

And independent message database, delivery delay, the second confirmation: Method two

Idempotence

Message end result will not be many times the cumulative consumer protection

Data Sheet guarantee uniqueness

• Use a unique ID to distinguish between business to ensure the uniqueness of the operation
• Benefits: simple
• Disadvantages: There are high concurrent database writes bottleneck
• Solution: sub-library sub-table queries, routing
• Using redis atom, distributed lock
  • Using the database and cache guarantee atomicity
  • Do not use a database, using a caching-only

confirm confirmation message

Message confirmation:

broker to confirm producer of messages.

step1: open acknowledgment mode channel.confirmSelect()step2: Add listens channeladdConfirmListener

return mechanism

return listener message processing for non-routable

Producers listening unreachable messages

A key item on the basis of configuration API:

Mandatory If true, the listener receives the routing unreachable message, and then for subsequent processing; for false message broker automatically deleted.

Consumer-side custom monitor

consumer inherit DefaultConsumerachievehandleDelivery

Limiting consumer side

Due to the high concurrent or delayed, resulting in a massive accumulation of the message queue.

Then all this huge amount of information pushed to the consumer, but the consumer a single client can not handle this huge amount of information at the same time.

auto ack to false

basic qos

Rabbitmq provides a Qos (Quality of Service) function. That is the premise of non-automatic acknowledgment, before if a certain number of news has not been confirmed, not for consumption.

basicQos(unit prefetchSize,ushort prefetchCount,bool global)

TODO: Clear implication here is, how to set the

• prefetchSize: how many messages take time
• prefetchCount: N messages when there is not ACK, consumer block, automatic answer, the setting is not effective.
• global: true based channel false: Based on consumer

The consumer side and back ACK queue

Consumer side Hand ACK and NACK

/ *  nack
  * @param deliveryTag 标签
     * @param multiple true 批量处理
     * @param requeue true 重回队列 扔到队尾
     */
channel.basicNack(envelope.getDeliveryTag(), false, true);


/**
 * ack
 */
channel.basicAck(envelope.getDeliveryTag(),false);
复制代码

Note: return (dead letter) to distinguish cohort (requeue) and dead-letter queue

TTL Time

The survival time of the message there are two kinds

• Specifies the message itself when sending specified survival time
• Message queue holding time: start to enter the queue message

Queue parameter

arguments

• Message TTL
• Max Lenth

Dead Letter Queue

DLX、Dead-Letter-Exchange

Definitions: When after the use of DLX into dead letter message in a queue, it can push back to another exchange, this exchange is called DLX.

Messages become dead letter case

• Message is rejected (basic.reject \ basic.nack), and requeue = false
• ttl expired, expired messages
• The maximum length of the queue

DLX is a normal exchange and other no difference, can be specified on any queue

When there are dead letter queue, RabbitMQ automatically republish the message exchange to set, is routed to another queue.

You can listen to the dead letter queue handled accordingly

Exchange:cdlx.exchange Queue:dlx.queue RoutingKey:#

x-dead-letter-exchange dlx.exchange

Dead letter queue flowchart:

Reproduced in: https: //juejin.im/post/5d030b75e51d45572c060039