方案（一）
消息落库，对消息状态进行打标（当前方案再高并发的场景下不合适）
step1
- 订单保存【 biz DB】
- 消息写入数据库【message DB】
step2
- 发送消息到 MQ （send message）
step3
- 消息端，对MQ中的消息进行确认
step4
- 回写数据库中消息的状态【message DB】
step5
- 定时任务，获取【message DB】中的未确认的消息
step6
- 对发送失败的消息，进行重新投递
- 重试次数大于 N 次的时候，标识为失败的消息
借助DB对消息状态打标签
方案（二）
消息的延迟投递，做二次确认，回调检查（节省了数据落地的操作）
发送了两次消息给MQ，第二个消息是延迟消息（几分钟之后），主要是作为回调检查使用的
延迟投递
