小编给大家分享一下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,被重新消费。代码如下：DeclareQueue.javaDeclareConsumer.java消息通过dlx转发的情况下，header头部会带有x-death的一个数组，里面包含消息的各项属性，比如说消息成为死信的原因reason，original-expiration这个字段表示消息在原来队列中的过期时间，根据这个值来确定下一次通知的延迟时间应该是多少秒。运行结果如下：看完了这篇文章，相信你对“RabbitMQ延迟队列如何实现订单支付结果异步阶梯性通知”有了一定的了解，如果想了解更多相关知识，欢迎关注百云主机行业资讯频道，感谢各位的阅读！
小编给大家分享一下CSS3怎么实现文字颜色的渐变，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！ 在文本上加上颜色渐变 这是一种将渐变色设置为文本的背景颜色。目前支持的浏览器是…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
