前言:
本章主要讲述下面以下内容:
1、消息如何保证100%的投递?
2、幂等性概念
3、Confirm确认消息
4、Return返回消息
5、自定义消费者
一,消息100%的投递
消息如何保障100%的投递成功?
什么是生产端的可靠性投递?
保障消息的成功发出
保障MQ节点的成功接收
发送端收到MQ节点(Broker)确认应答
完善的消息进行补偿机制
BAT/TMD互联网大厂的解决方案:
二,幂等性概念
幂等性是什么?
我们可以借鉴数据库的乐观锁机制
比如我们执行一条更新库存的SQL语句
Update t_repository set count = count -1,version = version + 1 where version = 1
Elasticsearch也是严格遵循幂等性概念,每次数据更新,version+1(博主博客前面有提到)
消费端-幂等性保障
在海量订单产生的业务高峰期,如何避免消息的重复消费问题?
消费实现幂等性,就意味着,我们的消息永远不会消费多次,即使我们收到了多条一样的消息
业界主流的幂等性操作
唯一ID+指纹码机制,利用数据库主键去重
利用Redis的原子性去实现
唯一ID+指纹码 机制
唯一ID+指纹码机制,利用数据库主键去重
Select count(1) from T_order where ID=唯一ID+指纹码
好处: 实现简单
坏处: 高并发下有数据库写入的性能瓶颈
解决方案: 根据ID进行分库分表进行算法路由
利用Redis的原子性去实现
使用Redis进行幂等,需要考虑的问题
第一:我们是否要进行数据落库,如果落库的话,关键解决的问题是数据库和缓存如何做到原子性?
第二:如果不进行落库,那么都存储到缓存中,如何设置定时同步策略?
三,Confirm确认消息
理解Confirm消息确认机制
消息的确认,是指生产者投递消息后,如果Broker收到消息,则会给我们生产者 一个应答。
生产者进行接收应答,用来确定这条消息是否正常的发送到Broker,这种方式也是消息的可靠性投递的核心保障
如何实现Confirm确认消息?
第一步:在Channel上开启确认模式:channel.confirmSelect()
第二步:在channel上添加监听:addConfirmListener,监听成功和失败的返回结果,根据具体的结果对消息进行重新发送、或记录日志等后续处理!
直接上代码吧
消费代码:
Consumer
package com.thf.rabbitmqapi.confirm;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.QueueingConsumer;
/**
* @au