对于消息的生产端的可靠投递，我们常见的解决方案有两种
1.消息落库，对消息状态进行打标
2.消息的延迟投递，做二次确认，回调检查
1、消息落库，对消息状态进行打标
上面图片为消息落库，对消息状态进行打标的常见步骤（状态0表示已发送，1表示已消费，2表示失败）
- 首先将将要发送的数据持久化到BIZ数据库中，并且创建一个存储着消息状态的数据持久化到MSG数据库中。
- 将数据发送至MQ。
- 消费者接收到数据，对数据进行消费然后将MSG在数据库中的状态修改为1。
- 在此之外，我们还存在一个分布式定时任务线程，用于定时查看是否有超时失败任务，当发现MSG数据库中存在着状态为0的数据则对数据进行重发，当数据多次重发失败后则将消息状态修改为2。
由于这个方式需要进行两个数据的数据落库容易产生数据库的性能瓶颈，所以我们更多的使用的是下一个可靠性投递的解决方式
消息的延迟投递，做二次确认，回调检查
上面图片时延迟投递的流程（upstream上游服务，downstream下游服务（消费端））
- 首先将需要发送的数据持久化到BIZ数据库。
- 将数据发送至MQ中。
- 消费者消费数据，并新建一个消费成功的消息进入MQ。
- Callback服务获取到消费者消费成功的消息后将消息持久化到MSG数据库。
- 生产者将延迟投递消息发送至MQ。
- Callback获取到延迟投递消息后进入MSG数据库查询是否投递成功，如果投递失败则进行失败补偿，这是向上游服务发送消息，让上游服务的查询BIZ数据库然后进行消息重发。