1. 什么是生产端的可靠性投递
- 保障消息的成功发出;
- 保障MQ节点的成功接收;
- 发送端收到MQ节点的确认应答;
- 完善的消息进行补偿机制。
2. 互联网大厂的解决方案
注意:在互联网大厂中,不加任何事务,事务将会造成严重的性能问题
2.1 消息落库,对消息状态进行打标;
分析: 该处理方式,需要将业务数据(BIZ DB)和消息数据(MSG DB)写入数据库,进行两次磁盘IO。在高并发场景下,显然不合适,开销较大,性能较低。在一些大厂中,这种方式用的比较少。
2.2 消息的延迟投递,做二次确认,回调检查。
- 先将业务数据信息写入数据库(BIZ DB);
- 同时生成两条消息(step1,step2),但是step2这条消息过几分钟之后才投递,是个延迟投递的过程;
- step1的消息发送到MQ Broker中—>消费端监听指定的队列---->收到消息并处理;
- 消费端成功消费完成消息后,自己再生成一条新的消息(确认消息 send confirm),发送给MQ;
- Callback service监听上一条所说的消费端发送的确认消息,收到确认消息后,然后将消息持久化到MSG DB;
- 几分钟之后,延迟投递消息发送给MQ,并让Callback server接收到该消息,此时检查MSG DB数据库,是否上一条已经持久化进数据库,如果成功,则不需要做任何处理;如果失败,则通过RPC通信告诉Upstream service,没有找到延迟检查的这条消息,需要重新发送。