rabbitmq 限制速度_3.rabbitmq消息发布时速度和可靠性的权衡(gold_axe)

快 可靠 2者的权衡

一般用绿框中这3种

以下以原生为例:

失败通知

消息没有地方可以去时 回调生产者的方法

使用: 发送消息时设置 mandatory 标志, 并且信道上加回调方法

效果: 不可路由, 就是没有队列消费, 就发还给生产者, 调生产者注册的失败回调

例子: direct的队列 以james为rountkey发送消息, 但是没有以james为绑定键的队列收对应消息

↓下面为信道上的回调方法 会被触发

//失败通知 回调, 根本么有队列收消息时 消息会返回到这

channel.addReturnListener(new ReturnListener() {

public void handleReturn(int replyCode,

String replyText,

String exchange,

String routeKey,

AMQP.BasicProperties basicProperties,

byte[] bytes//返回的消息

) throws IOException {

System.out.println("返回的message:"+new String(bytes));

System.out.println("返回的replycode:"+replyCode);

System.out.println("返回的replyText:"+replyText);

System.out.println("返回的exchange:"+exchange);

System.out.println("返回的routeKey:"+routeKey);

/*

*

*

Sent Message: [james]:'Hello World_2_1605340829185'

返回的message:Hello World_2_1605340829185

返回的replycode:312

返回的replyText:NO_ROUTE

返回的exchange:mandatory_test

返回的routeKey:james

* */

}

});

发送时开启mandatory

事务

事务的实现主要是对信道(Channel)的设置，

主要分为启动事务、提交事务、回滚事务。

不推荐!

事务机制本身 会带来大问题：

1、严重的性能问题 2~10倍

2、使生产者应用程序产生同步(失去了mq的异步行)

发送者 确认

比事务更轻量，性能影响几乎可以忽略不计。

也是发送方的信道上的,

一般和 失败通知 一起用,

失败确认是没队列收消息, 这边是处理消费者内部消费的时候坏了

使用: 在信道上开启一下, 发了以后再去信道拿结果

1.一般确认

2.批量确认

这种批量确认, 如果 任何一条没成功, 都会抛出异常来应答

3.异步监听确认

比上面2个确认 更快

不是堵塞拿结果,而是设置回调方法

多条都是成功的话, 可能会只调一次 :

这个结果可能是这样:

send_ACK:1,multiple:false

send_ACK:6,multiple:true

send_ACK:13,multiple:true

send_ACK:15,multiple:true

send_ACK:17,multiple:true

send_ACK:19,multiple:true

send_ACK:20,multiple:false

下次发一般又不同了

备用交换器

如果主交换器无法路由消息，那么消息将被路由到这个新的备用交换器

这里即使有绑定了失败通知, 也不会触发,

因为失败了就去备用交换器了

这里和备用交换器的声明有点像,都是map写死一个规定的key传名字,备用交换器是主交换器声明的时候给主交换器的

备用交换器就一普通的交换器,

只是主交换器声明的时候把备用的交换器名字传进去就行了