RabbitMQ学习第七章:消息确认机制之事务机制
RabbitMQ消息确认机制之事务机制。
RabbitMQ中,我们可以通过持久化数据 解决RabbitMQ服务器异常
的数据丢失问题。
问题:生产者将消息发送出去,消息到底有没有到达RabbitMQ服务器
默认的情况下是不知道的。
两种方式:
1.AMQP实现了事务机制,类似mysql的事务。
事务机制三个方法:
txSelect:用于将当前changel设置成transation模式。
txCommit:用于提交事务。
txRollback:回滚事务。
通过txSelect开启事务后,便可以发送消息给RabbitMQ服务器,通过
txCommit提交成功,如果提交之前出现了异常,就txRollback回滚。
问题:开启-提交-回滚,每次提交,都相当于一次请求,降低了消息的吞吐量,
因为走的通信太多,大量消息就会大量请求服务器,很耗时。
例:
生产者
消费者:
图中发送消息逻辑没有问题,所以发送的消息会成功
如果生产者代码中执行了错误的逻辑,比如:
这时候再发送消息,就会失败,并回滚。
2.confirm模式。
生产者端confirm实现原理:生产者将信道设成confirm模式,一旦信道进入到
confirm模式,所有在该信道发布的消息都会指派一个唯一消息id,一旦消息被投
递到所匹配的队列之后,就会发送一个确认给生产者(包含消息id),
这就使得生产者知道了这个消息已经正确到达了队列。如果消息和队列是可持久
化的,确认消息会将消息写到磁盘后在发出。
Confirm模式最大的好处在于它是异步的。
开启confirm模式:channel.confirmSelect();
编程模式:
2.1.普通:发过去(一条)后会调用waitForConfirms()(串行)。
2.2.批量:发过去(一批)后会调用waitForConfirms()(串行)。
2.3.异步confirm:提供一个回调方法,服务端confirm一条或多条后客户端会调用。
例:
Confirm普通模式 生产者:
消费者:
Confirm批量模式(普通模式+for循环) 生产者:
消费者:
confirm模式-异步
channel对象提供的confirmListener()回调方法只包含deliveryTag(当前channel发出
的消息序号),我们需要自己为每一个channel维护一个unconfirm的消息序号集合,
每publish一条数据,集合中元素加1,每回调一次handleAck方法,unconfirm集
合删掉相应的一条(multiple=false)或多条(multiple=true)记录,从程序运行效
率上看,这个unconfirm集合最好采用有序集合SortedSed存储结构
最新文章
- Eclipse JAVA文件注释乱码
- dns服务
- (转载)eclipse插件安装的四种方法
- 1304: [CQOI2009]叶子的染色 - BZOJ
- Bootstrap 内核引用(一)
- NS实现采用的技术大多是PHP,如果采用java、 .net是否同样适用?
- vim常用命令总结 (转)
- linux下卸载和安装mysql数据库的方法
- linux中的重要目录
- PE格式第七讲,重定位表
- CDH升级
- java之Spring(AOP)前奏-动态代理设计模式(上)
- 记录es在虚拟机的开启步骤
- Maven和Solr简单总结
- MySQL--表操作(约束条件foreign key关联表 多对1,多对多,1对1)
- C#的static
- [2017BUAA软件工程]第0次个人作业
- 【codeforces 768F】 Barrels and boxes
- html to docx
- 添加List集合覆盖问题
热门文章
- TensorFlow中的Variable 变量
- Property or method ";scope"; is not defined on the instance but referenced during render. Make sure that this property is reactive, either in the data option, or for class-based components
- oracle 导出导入表 不到出指定表
- Unity 使用IO流获取PNG/JPG/GIF/BMP的宽高【转】
- 关闭Mac的Microsoft AutoUpdate弹框提示
- Centos操作系统在虚拟机VMware上的安装(二)
- 自定义注解获取请求Header中的值
- Spring 事务传播属性
- vue.cli的安装配置
- git技能树总结