一、生产端-可靠性投递
解决方案：消息落库，对消息状态进行打标
为确保消息可靠性发送，在业务处理完后，生产端发送消息时消息落库（最好保证业务和消息落地在同一事务），发送给MQ后收到MQ的确认消息时，标记消息已发送成功。若生产端接口确认消息时，网络中断导致无法收到确认消息，此时需要做补偿操作，使用分布式定时任务，扫描未标记成功发送的消息，重新发送或其他操作。
二、消费端-幂等性保障
在海量订单产生的业务高峰期，如何避免消息的重复消费问题？
业界主流的幂等性操作：业务唯一ID或指纹码机制，利用数据库主键去重。
根据ID查询，再确认是否插入，避免重复问题
三、生产端-确认机制
1.Confirm消息确认机制
消息的确认，是指生产者投递消息后，如果broker收到消息，则会给生产者一个应答
生产者进行接收应答，用来确定这条消息是否正常的发送到broker，这种方式也是消息的可靠性投递的核心保障
2.Confirm确认消息的实现
第一步：在channel上开启确认模式：change.confirmSelect();
第二步：在channel上添加监听：addConfirmListener，监听成功和失败的返回结果，根据具体的结果对消息进行重新发送或记录日志等后续处理。
四、生产端-返回机制
1.Return消息机制
Return Listener用于处理一些不可路由的消息
我们的消息生产者，通过指定一个Exchange和Routingkey，把消息送到某一个队列中去，然后我们的消费者监听队列，进行消费处理
但是在某些情况下，如果我们在发送消息的时候，当前的exchange不存在或者指定的routingkey路由不到，这个时候如果我们需要监听这种不可达的消息，就要使用Return Listener
2.实现
第一步：发送消息时，设置Mandatory：如果为true，则监听器会接收到路由不可达的消息 ，然后进行后续处理，如果为false，那么broker端自动删除该消息
第二部：在channel上添加监听:addReturnListener，监听一些不可路由的消息，后续记录日志或其他处理
网友评论