rabbitmq的发送确认机制中需要confirm或者return
需要broker确认
这个感觉和事务没啥区别了啊
事务也是broker确认啊
为什么说发送确认机制就是轻量级,对吞吐量折损没有事务高呢?
另外rabbitmq的发送确认机制有超时机制吗?
rabbitmq的发送确认机制中需要confirm或者return
需要broker确认
这个感觉和事务没啥区别了啊
事务也是broker确认啊
为什么说发送确认机制就是轻量级,对吞吐量折损没有事务高呢?
另外rabbitmq的发送确认机制有超时机制吗?
15 回答8.4k 阅读
8 回答6.2k 阅读
1 回答4k 阅读✓ 已解决
3 回答2.2k 阅读✓ 已解决
2 回答3.1k 阅读
2 回答3.8k 阅读
3 回答1.7k 阅读✓ 已解决
confirm 模式 和 事务模式的功能的确类似,保证消息不会丢失并且被准确消费。
当开启了事务模式后,只有当一个事务被所有的mirrors接受之后,
tx.commit-ok
才会返回给客户端。confirm模式和开启事务模式都可以保证"被所有的mirrors接受"。
不同点除了性能差距,在于confirm是针对一条消息的,而事务是可以针对多条消息的(当然是针对同一个queue的多条消息)。另外就是,confirm模式只是针对publisher的设置,而事务模式即可以针对publisher,也可以针对consumer。如果针对publisher设置事务模式,则我们可以将多个basic.publish方法放在一个事务中,当所有的publish的消息被所有的mirrors接受后,publisher client会收到
tx.commit-ok
的方法。如果针对consumer设置事务模式,则我们可以将多个basic.ack方法放在一个事务中,收到tx.commit-ok
时表示这些消息都被确认了。至于confirm模式和事务模式的性能差距,普通confirm模式和事务模式相差不对,批量confirm和异步confirm会有性能优势,你可以自己测试一下收获更多。参考这篇文章
https://blog.csdn.net/u013256...;
https://cloud.tencent.com/dev...
另外超时机制的问题
RabbitMQ仅仅通过Consumer的连接中断来确认该Message并没有被正确处理。也就是说,RabbitMQ给了Consumer足够长的时间来做数据处理。
希望能帮到你。