要求
- 保障消息的成功发出
- 保障 Broker 的成功接收
- 发送端到 Broker 的确认应答
- 完善的消息补偿机制
解决方案
消息信息落库，对消息状态进行打标
- 高并发不合适
- step1
- 业务信息入库
- 消息信息入库
- 状态标识设置0
- step2
- 发送消息给 broker
- step3
- 监听 broker confirm
- step4
- broker confirm，则对消息信息打标为1
- step5
- 有个定时任务，判断消息信息的状态标志是否为0，且是否超时
- 符合条件，进行重发
- step6
- 限制重发次数，达到阈值，打标为2
延迟消息
- 高并发合适，减少了 db 操作
- step0
- 业务信息落库
- step1
- 业务落库后立马发送第一条业务消息
- step2
- 接着马上发送一个延迟投递消息
- step3
- 消费端监听且消费业务消息
- step4
- 消费端发送一条确认消息(也是一条mq消息)
- step5
- callback 服务监听确认消息
- 收到后进行消息落库
- step6
- callback 服务监听延迟投递消息
- 查询库中是否有对应的确认消息落库，如果没有，告诉生成端需要重新发送消息
若有收获，就点个赞吧
0 人点赞
