超级会员免费看
本文介绍了如何设计和封装一套支付系统中的重试组件，特别是针对RabbitMQ的死信队列实现延迟重试。文章讨论了重试场景，分析了各种重试实现方式，包括扫表、中间件特性、框架支持和自定义实现。接着，详细阐述了组件的封装过程，包括需求分析、模块设计（持久化和重试模块）以及业务端的使用方法。最后，总结了该组件的优点和应用场景。
文章目录
前言
如何封装一套服务自身业务开箱即用的重试组件？是个值得思考的问题！
在开发支付系统过程中，我们经常会遇到这样的业务场景：调用下游系统、回调上游系统，由于网络原因或者当时对方系统不可用导致调用失败，那么调用失败就失败了么？当然肯定不是，一般都要有重试机制。这种重试机制实现有很多方式，但是万万不可依赖其他系统的重试机制去重试你要重试调用的系统，这个原因下面分析。本篇文章就重试场景给出一个个人觉得还不错的解决方案，也是作者所在用的解决方案，如有更好的解决方案欢迎交流。
一、重试场景分析
在支付系统中我们经常会将一些非核心业务流程做成异步的，在核心主流程中往MQ写入一条相对应的待处理消息，写入成功即认为业务处理成功了，所以我们要证在消费端最大程度的保证处理成功。
在结果通知中也有失败重试策略，我们对接支付渠道如支付宝：如果不返回指定成功的报文信息其将在25小时以内完成8次通知（通知的间隔频率一般是4m,10m,10m,1h,2h,6h,15）。
这里我们分析个场
订阅专栏 解锁全文
5521
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
