3.rabbitmq消息发布时速度和可靠性的权衡(gold_ax
2020-11-15 本文已影响0人
胖达_4b7e
快 可靠 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传名字,备用交换器是主交换器声明的时候给主交换器的
备用交换器就一普通的交换器,
只是主交换器声明的时候把备用的交换器名字传进去就行了