生产端的可靠投递
需要满足四点
1.保障消息的成功发出
2.保障MQ节点的成功接收
3.发送端收到MQ节点(broker)确认应答
4.完善的消息进行补偿机制
方式一:消息落库
成功情况:在第一步 设置MSG DB status:0 第二步,第三步,第四步成功设置 status:1
异常情况:在第二步和第三步可能出现RPC网络闪断等问题问题导致消息投递失败或者confirm失败 所以status 还是为0 在第五步需要获取status为 0的数据进行重新投递(也就是第六步)如果还是投递失败则进行重试3次(也就是第七步),在第五步中获取status为0的数据时,需要设置超时时间(5分钟内没有confirm的消息才算是投递失败需要定时任务重新投递),不然刚投递的消息还没有进行status的更新就又被投递了但是其实已近投递成功了的
缺点是:在第一步需要更新或者插入操作数据库2次
在大厂中 都不会加事务,都是进行的补偿操作。
优化:不需要消息进行持久化 只需要业务持久化
方式二--消息的延迟投递,做二次确认,回调检查
第一步:(上游服务:Upstream service)业务入库 然后send 消息到broker这两步是有先后顺序的
然后再第二步进行消息延迟发送到新的queue(延迟时间为5分钟:业务决定)
第三步(下游服务:Downstream service)监听到消息然后处理消息
第四步 下游服务send confirm生成新的消息到broker (这里是一个新的queue)
第五步 callback service 去监听这个消息 并且入库 如果监听到表示这个消息已经消费成功
第六步 callback service 去检查 第二步投递的延迟消息是否 在msgDB里面是否消费成功,不存在或者消费失败就会 Resend command
这里面绿色 红色 蓝色都是新生成的queue不会共用queue
如果在第1,2,4步失败 ,如果成功 broker会给我们一个confirm,失败当然没有,这是消息可靠性投递的重要保障