消息落库，对消息状态打标。+轮训
状态0，未处理，1：已经处理，2：失败（需要补偿机制）。
- 将业务订单数据和生成的Message进行持久化操作
- 将Message发送到Broker服务器中
- 通过RabbitMQ的Confirm机制，在producer端，监听服务器是否ACK。
- 如果ACK了，就将Message这条数据状态更新为已发送。如果失败，修改为失败状态。
- 分布式定时任务查询数据库3分钟（这个具体时间应该根据的时效性来定）之前的发送失败的消息
- 重新发送消息，记录发送次数
- 如果发送次数过多仍然失败，那么就需要人工排查之类的操作。
优点：
能够保证消息百分百不丢失
缺点：
第一步中涉及到分布式事务问题，分布式事务一点会降低时效性。
消息的延迟投递，做二次确认，回调检查。
流程图中，颜色不同的代表不同的message
- 将业务订单持久化
- 发送一条Message到broker(称之为主Message)，再发送相同的一条到不同的队列或者交换机(这条称为确认Message)中。
- 主Message由实际业务处理端消费后，生成一条响应Message。之前的确认Message由Message Service应用处理入库。
4~6. 实际业务处理端发送的确认Message由Message Service接收后，将原Message状态修改。 - 如果该条Message没有被确认，则通过rpc调用重新由producer进行全过程。
优点：
相对于数据库持久化方案来说响应速度有所提升
缺点：
系统复杂性有点高
万一两条消息都失败了，消息存在丢失情况，仍需Confirm机制做补偿
