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存储结构