## 生产端的可靠性投递 1. 保障消息的成功发出; 2. 保障MQ节点的成功接收; 3. 发送端收到MQ节点(broker)确认应答; 4. 完善的消息进行补偿机制; ## 生产端-可靠性投递 1. 消息入库,对消息状态进行打标;对于消息状态没有投递成功的进行轮询投递;尝试一定的次数再去轮询发送; 2. 消息的延迟投递,做二次确认,回调检查; ## 消息落库 1. 消息入库; 对于多张表,小规模的并发可以加事务;在高并发的情况下,不要加事务; 2. 发送消息到broker; 3. 等待broker回复消息;更新数据库的消息,将消息的状态修改为已发送; 4. 如果生产端没有接收到broker的确认消息,那么使用另外一个定时任务,对超时几分钟还没收到的消息进行再次发送; **这里往数据库插入两条数据,一条是对业务数据的添加或修改,一条是插入消息的实体记录到数据库**;  ## 延迟投递,二次确认,回调检查 消息落库的方式要进行两次的数据库操作,那么在高并发的场景下,这样肯定是不适合的; 1. 消息入库BIZ DB,只入一次库; 2. 生产端发送两条消息,第一条立刻发送,第二条延迟5分钟发送到callback中; 并且这两个消息是发送到不同的exchange或queue里面的; 3. 当消费端消费消息第一个消息后,再里面除开ack后再发送一条消息到callback服务中,callback将这条记录入库.说明这条记录已经处理完成; 4. 延迟的消息5分钟后到了callback服务中,此时检查MSG DB,发现消息已经处理过,则丢弃; 5. 如果发现MSG DB中没有此条消息,那么说明消息没有被处理,此时callback服务再调用上游服务,重新发送两条消息,直到成功为止; **使用回调检查的目的,不是100%的保证消息的投递性,而是减少一次消息的入库,这样在并发的情况下可以大大提高并发性. 这样就将回调检查的流程剥离主流程**