mq

投递流程

消息投递到exchang，根据路由key路由到对应queen

exchang类型

direct、topic、fanout、hearders
direct精确匹配，topic模糊匹配
通常使用fanout（不用路由，效率最快，默认使用）

可靠性投递方案

1. 消息落库，本地db存储（业务存储、消息存储），投递返回成功，修改数据状态，状态长时间未改，补偿策略重新投递；
   BIZ DB：订单数据库(或其他具体业务)
   MSG DB：消息数据库
   第1步：将订单入库，创建一条MSG(状态为0) 入MSG DB库
   第2步：将消息发出去
   第3步：监听消息应答(来自Broker)
   第4步：修改消息的状态为1(成功)
   第5步：分布式定时任务抓取状态为0的消息
   第6步：将状态为0的消息重发
   第7步：如果尝试了3次(可按实际情况修改)以上则将状态置为2(消息投递失败状态)
2. 延迟投递，少一次db，消息同时投递两条，一条延时投递，回调服务接受第一条投递结果，投递成功存库，延时投递
   

第二种方案可以避免消息对象与业务对象同时入库

Upstream service：上游服务，可能为生产端
Downstream service：下游服务，可能为消费端
MQ Broker：可能为集群
Callback service：回调服务，监听confirm消息

第1步：首先业务数据落库，成功才后第一次消息发送
第2步：紧着着发送第2条消息（可以用于寻找第1条消息），用于延迟(可能2,3分钟后才发送)消息投递检查
第3步：Broker端收到消息后，消费端进行消息处理
第4步：处理成功后，发送confirm消息
第5步：收到confirm消息后，将消息进行持久化存储
第6步：收到了delay消息，检查DB数据库，若对应的第1条消息已处理完成，则不做任何事情；若收到了delay消息，检查DB数据库，发现对应的第1条消息处理失败(或无记录)，则发送重传命令到上游服务，循环第1步