RabbitMQ 延迟队列实现订单支付结果异步阶梯性通知

在第三方支付中，例如支付宝、或者微信，对于订单请求，第三方支付系统采用的是消息同步返回、异步通知+主动补偿查询的补偿机制。

由于互联网通信的不可靠性，例如双方网络、服务器、应用等因素的影响，不管是同步返回、异步通知、主动查询报文都可能出现超时无响应、报文丢失等情况，所以像支付业务，对结果的通知一般采用几种方案结合的补偿机制，不能完全依赖某一种机制。
例如一个支付结果的通知，一方面会在支付页面跳转时候返回支付结果（一般只用作前端展示使用，非最终状态），同时会采用后台异步通知机制（有前台、后台通知的，以后台异步通知结果为准），但由于前台跳转、后台结果通知都可能失效，因此还以定时补单+请求方主动查询接口作为辅助手段。
常见的补单操作，任务调度策略一般设定30秒、60秒、3分钟、6分钟、10分钟调度多次（以自己业务需要），如果调度接收到响应确认报文，补单成功，则中止对应订单的调度任务；如果超过补单上限次数，则停止补单，避免无谓的资源浪费。请求端随时可以发起请求报文查询对应订单的状态。

在日常开发中，对于网站前端来说，支付计费中心对于订单请求信息的处理也是通过消息同步返回、异步通知+主动补偿查询相结合的机制，其中对于订单的异步通知，目前的通知策略为3s、30s、60s、120s、180、300s的阶梯性通知。返回成功情况下就不继续通知了，本来打算使用将失败的消息写到数据库等待发送，然后每秒查询数据库获取消息通知前端。但觉得这样的处理方式太粗暴。存在以下缺点：

1 、每秒请求有点儿浪费资源； 2 、通知方式不稳定； 3 、无法承受大数据量等等

所以最终打算使用rabbitmq的消息延迟+死信队列来实现。消息模型如下：

producer发布消息，通过exchangeA的消息会被分发到QueueA,Consumer监听queueA，一旦有消息到来就被消费，这边的消费业务就是通知前端，如果通知失败，就创建一个延迟队列declareQueue，设置每个消息的ttl然后通过declare_exchange将消息分发到declare_queue,因为declare_queue没有consumer并且declare_queue中的消息设置了ttl，当ttl到期后，将通过DEX路由到queueA,被重新消费。