4 rabbitmq高級特性

時間 2019-12-07

標籤 rabbitmq 高級特性欄目 RabbitMQ 简体版

原文原文鏈接

RabbitMQ主要有如下高級特性

可靠性投遞(100%投遞成功)java
冪等性(解決重複消費)redis
confirm機制、return機制數據庫
自定義消費者緩存
消息的Ack和重回隊列併發
消息限流分佈式
TTL消息高併發
死信隊列fetch

100%投遞成功(可靠性投遞)

生產端的可靠性投遞spa

保證消息成功發送
保障MQ節點成功接收
發送端收到MQ的Ack
完善的消息進行補償機制

解決方案3d

方法一: 消息入庫、對消息狀態標記
方法二: 消息的延遲投遞、二次確認、回調檢查

方法1:消息入庫、定時任務補償

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

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

方法二:消息和數據庫無關、延遲投遞、二次確認

冪等性

消息端屢次消費保障結果不會累計

數據表保障惟一性

使用業務惟一ID區分，保障操做的惟一性
好處:實現簡單
壞處:高併發有數據庫寫入瓶頸
解決方案:分庫分表查詢、路由
利用redis原子性、分佈式鎖
- 使用數據庫和緩存保障原子性
- 不使用數據庫，只使用緩存

confirm 確認消息

消息的確認:

broker給producer的confirm報文。

step1: 開啓確認模式 channel.confirmSelect() step2: 在channel添加監聽 addConfirmListener

return 機制

return listener 用於處理不可路由的消息

生產者監聽不可達的消息

在基礎API有一個關鍵配置項：

Mandatory 若是爲true，則監聽器接收到路由不可達的消息，而後進行後續處理；若是爲false則broker自動刪除這些消息。

消費端自定義監聽

consumer 繼承 DefaultConsumer 實現 handleDelivery

消費端的限流

因爲高併發或延遲，致使隊列中堆積巨量的消息。

而後這巨量的消息所有推送給消費者,可是單一的消費客戶端沒法同時處理這巨量的消息。

auto ack 設爲 false

basic qos

Rabbitmq提供了一種Qos(服務質量保證)的功能。即在非自動確認的前提下，若是必定數目的消息未被確認前，不進行消費。

basicQos(unit prefetchSize,ushort prefetchCount,bool global)

TODO: 搞清楚這裏的含義，怎麼設置的

prefetchSize: 一次拿多少條消息
prefetchCount: 當有N條消息未ACK,consumer block ,自動應答時，該設置不生效。
global: true基於channel false:基於consumer

消費端的ACK和重回隊列

消費端的手工ACK和NACK

/ *  nack
  * @param deliveryTag 標籤
     * @param multiple true 批量處理
     * @param requeue true 重回隊列 扔到隊尾
     */
channel.basicNack(envelope.getDeliveryTag(), false, true);


/** * ack */
channel.basicAck(envelope.getDeliveryTag(),false);
複製代碼

注意:重回隊列(requeue)和死信隊列(dead letter)區別