共计 2999 个字符，预计需要花费 8 分钟才能阅读完成。
Hello，大家好，我是楼下小黑哥~
好久没写领取相干的文章了，明天持续从事老本行~
上次在文章钱被扣走了，然而订单却未胜利！领取掉单异样最全解决方案提到，领取过程会呈现 掉单、卡单 的状况，这种状况对于用户来讲，体验十分差，明明本人付了钱，扣了款，然而订单却未胜利。
上篇文章咱们简略说了下解决方案，这次小黑哥就联合生产理论碰到的状况，给出两种具体设计的计划：
- 定时轮询弥补计划
- 提早音讯弥补计划
大家能够依据本人零碎的理论状况，选择性参考。
当然了，以下设计方案可能并不完满，如果各位读者还有其余解决方案，欢送留言指出，一起探讨，一起成长~
欢送关注我的公众号：小黑十一点半，取得日常干货推送。如果您对我的专题内容感兴趣，也能够关注我的博客：studyidea.cn
定时轮询弥补计划
整体流程
这个计划次要采纳定时工作，批量查问掉单记录，从而驱动查问具体领取领取后果，而后更新外部订单。
整体计划流程图如下：
前三步流程没什么好说的，失常的领取流程，咱们针对前面几步具体具体说下。
第三步调用领取通道之后，如果领取通道端返回 领取受理胜利或者领取解决中，咱们就须要调用第四步，将这类订单插入掉单表。
如果领取间接胜利了，那就失常流程返回即可。
温习一下，网关类领取，比方支付宝、微信领取、网银领取，这种领取模式，领取通道仅仅返回领取受理胜利，具体领取后果须要接管领取通道端的领取告诉，这类领取咱们将其称为异步领取。
相应的还有同步领取，比方银行卡领取，微信、支付宝代扣类领取，这类领取，同步就能返回领取后果。
第五步，补单利用将会定时查询数据库，批量查问掉单记录。
第六步，补单利用应用线程池，多线程异步的形式发动掉单查问。
第七步，调用领取通道领取查问接口。
重点来了，如果第七步领取后果查问为以下状态：
- 领取后果为扣款胜利
- 领取后果为明确失败
- 掉单记录查问达到最大次数
第八步就会删除掉单记录。
最初，如果掉单查问仍旧还是解决中，那么通过肯定的延时之后，反复第五步，再次从新掉单弥补，直到胜利或者查问达到最大次数。
相干问题
为什么须要新建一张掉单表？不能间接应用领取订单表，查问未胜利的订单吗?
这个问题，实际上的确能够间接应用的领取订单表，而后批量查问当天未胜利的订单，补单程序发动领取查问。
那为什么须要新建一张掉单表？
次要是因为数据库查问效率问题，因为领取订单表每天都会大量记录新增，随着工夫，这张表记录将会越来越多，越来越大。
领取记录越多，批量范畴查问效率就会变低，查问速度将会变慢。
所以为了查问效率，新建一张掉单表。
这张表里仅记录领取未胜利的订单，所以数据量就会很小，那么查问效率就会很高。
另外，掉单表里的记录，不会被永恒保留，只是临时性。当领取后果查问胜利，或者领取后果明确失败，再或者查问次数达到规定最大次数，就会删除掉单记录。
这就是第八步为什么须要删除掉单表的起因。
如果须要保留每次掉单表查问详情，那么这里倡议再新增一张掉单查问记录表，保留每一次的查问记录。
针对这个计划，如果还有其余问题，欢送留言。
计划优缺点
定时轮询弥补计划，最大的长处可能就是零碎架构计划比较简单，比拟容易施行。
那么这个计划的毛病次要在于 定时工作 上。
定时工作轮询计划人造会存在以下有余：
- 轮询效率稍低
- 每次查询数据库，曾经被执行过记录，依然会被扫描（补单程序将会依据肯定策略决定是否发动领取通道查问），有 反复计算 的嫌疑
- 时效性不够好，如果每小时轮询一次，最差的状况下，时间误差会达到 1 小时
- 如果为了解决时效性问题，减少定时工作查问效率，那么 1 中查问效率跟 2 的反复计算问题将会更加显著。
提早音讯弥补计划
上面介绍另外一种掉单弥补计划，提早音讯弥补计划，这个计划整体流程与定时工作计划相似，最大区别可能在于，从一种 拉模式 变成一种 推模式。
整体计划流程图如下：
这个计划次要流程跟定时计划相似，次要区别在于第四步，第五步，第八步。
第四步的流程从插入掉单表变更为往 提早队列发送掉单音讯。
第五步，补单程序接管掉单音讯，而后触发领取掉单查问。
第八步，如果第七步领取后果查问为以下状态：
- 领取后果为扣款胜利
- 领取后果为明确失败
- 掉单记录查问达到最大次数
补单程序将会告知提早队列生产胜利，提早队列将会删除这条掉单音讯。
其余状态将会告知生产生效，提早队列将会在肯定延时之后，再次发送掉单音讯，而后持续反复第五步。
提早队列
这里的提早队列须要本人实现，复杂度还是比拟高的，这里给大家举荐几种实现计划：
第一种，基于 Redis SortedSet 实现提早队列。能够参考一下有赞的实现计划 https://tech.youzan.com/queuing_delay/
第二种，基于工夫轮算法 (TimingWheel) 实现提早队列，具体能够参考 Kafka 延时队列。
第三种，基于 RocketMQ 提早音讯。
前两种计划说起来还须要再开发，所以还是比较复杂的。
这里重点说下第三种计划，该计划是 RocketMQ 曾经反对的个性，开箱即用，应用起来还是比较简单的。
RocketMQ 提早音讯反对 18 个等级，别离如下：
1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h音讯发送方能够通过以下形式指定提早等级，对应上方的延迟时间。
Message#setDelayTimeLevel音讯生产方，如果生产失败，默认将会在音讯发送方的的提早等级根底上加 1。如果音讯生产方须要指定其余的提早等级，能够应用如下形式：
ConsumeConcurrentlyContext#setDelayLevelWhenNextConsumeRocketMQ 提早音讯，反对的个性还是比拟根底、简略，不反对自定义延迟时间。不过对于掉单弥补的这个场景刚好够用，然而如果须要自定义提早的，那还是得采纳其余的计划。
计划优缺点
提早音讯的计划绝对于定时轮询计划来讲：
- 无需再查问全副订单，效率高
- 时效性较好
不过提早音讯这种计划，须要基于 提早队列，实现起来比较复杂，目前开源实现也比拟少。
小结
领取掉单、卡单是领取过程中常常会碰到的事，咱们能够采纳异步弥补的计划，解决该问题。
异步弥补计划能够采纳如下两种：
- 定时轮询弥补计划
- 提早音讯弥补计划
定时轮询弥补计划实现起来比较简单，然而时效性稍差。
而提早音讯弥补计划总体来说比拟优良，然而实现起来比较复杂。如果没有自定义的延迟时间的需要，能够间接采纳 RocketMQ 提早音讯，简略快捷。
另外 提早队列 应用场景还是比拟多，不仅仅能用在掉单弥补上，还能够用于领取关单等场景。所以有能力开发的团队，能够开发一个通用的提早队列、
好了，明天的文章就到这里了。
我是楼下小黑哥，下篇文章再见，886~
欢送关注我的公众号：小黑十一点半，取得日常干货推送。如果您对我的专题内容感兴趣，也能够关注我的博客：studyidea.cn
历史领取文章举荐
- 钱被扣走了，然而订单却未胜利！领取掉单异样最全解决方案
- 一笔订单，然而误付了两笔钱！这种反复付款异样到底该如何解决？
- 收款神器！解读聚合收款码背地的原理 | 原创
- 手机没网了，却还能领取，这是什么原理？| 原创
- 微微一扫，立即扣款，付款码背地的原理你不想晓得吗？| 原创
- 领取渠道路由零碎进化史
- 从零开始设计对账零碎
- 微信支付宝接入大全
- 多领取通道路由网关设计
- 银行卡领取，背地到底产生了什么？
欢送关注我的公众号：小黑十一点半，取得日常干货推送。如果您对我的专题内容感兴趣，也能够关注我的博客：studyidea.cn