RabbitMq中的生产者确认机制

在使用RabbitMq的时候,可以通过消息持久化操作来解决服务器异常崩溃导致的消息丢失,但是如何保证消息正常到达RabbitMq呢?
事务机制
RabbitMq中与事务相关的操作一共有三个:channel.txSelect,channel.txCommit,channel.txRollback。channel.txSelect用于将当前信道设置为事务模式,channel.txCommit用于事务提交,channel.txRollback用于事务回滚。在通过channel.txSelect将当前信道设置为事务模式后,我们就可以向RabbitMq发送消息了,如果消息正常发送并且被RabbitMq接收,那么事务提交成功,否则捕捉异常并进行事务回滚。
在这里插入图片描述
需要注意的是,开启事务后,性能影响可能会很大(因为比普通发送多了四个步骤Tx.select,Tx.select-OK,Tx.commit,Tx.commit-Ok / Tx.select,Tx.selectOK,Tx.Rollback,Tx.Rollback-Ok),建议使用发送者确认机制。
确认机制
生产者将信道设置成confirm(确认)模式,一旦信道进入confirm模式,所有在该信道上面发布的消息都被被指派一个唯一的ID,一旦消息被投递到匹配的队列后,RabbitMq会发送一个确认标志(Basic.Ack+消息的唯一ID)给生产者,生产者确认消息已经正确到达目的地(如果消息和队列是持久化的,确认消息会在消息写入磁盘后发出)。
事务机制在一条消息发送后会使发送端阻塞,以等待RabbitMq的回应然后才能继续下一条消息。相比之下发送发确认机制最大的好处是异步的,一旦发送一条消息,生产者应用程序可以一边等待信道返回确认(通过回调方法处理确认消息)一边发送下一条消息,如果RabbitMq因为自身内部错误导致消息丢失,就会发送一条nack(Basic.Nack)命令,生产者同样可以在回调方法中处理该命令。
确认机制相比事务机制性能提升的点有两处:

  1. 命令帧报文的减少
    同步等待的方式下,正常发送一条消息,确认机制需要通信交互的命令有两条:Basic.Publish和Basic.Ack;事务机制是三条:Basic.Publish,Tx.Commit,Tx.Commit-Ok。事务机制多了一个命令帧报文的交互,所以QPS会略微下降。
  2. 批量确认或者异步确认机制。
    确认机制的优势在于并不一定需要单条消息同步确认,可以使用批量确认或者异步确认机制。在批量确认方法中,客户端程序需要定期或者定量,亦或者两者结合起来调用channel.waitForConfirms来等待RabbitMq的确认返回,虽然可以极大的提升效率,但是问题在于出现Basic.Nack或者超时情况时,发布者需要将这一批量的消息全部重发,这会带来明显的重复消息数量,并且当消息经常丢失时,性能是不升反降的。
    在这里插入图片描述
    异步确认需要在channel接口中的addConfirmListener方法中添加ConfirmListener这个回调接口,其中包括两个方法handleAck和handleNack,分别用来处理RabbitMq回传的Basic.Ack和Basic.Nack。
    在这里插入图片描述
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值