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