业务架构体系
通过图可以看出在功能架构上跟传统的实体电商业务功能上有些是重合的，但也有自己特殊的功能架构，主要
体现在虚拟业务技术实现上的一些特点，比如以话费充值为例，在技术实现上我们就需要考虑以下的一些特殊的业
务场景：
- 余额/押金导致的供应商轮转
- 接口调用失败之后的重试
- 重试次数的阈值限定，超过后的退款等业务
- 对接成功，接口回调的后续业务处理
- 主动的状态检查，接口回调的补偿
在这些业务场景的实现过程中衍生出了虚拟交易特殊的策略系统：延迟任务系统
延迟任务系统架构
延迟任务：顾明思议，我们把需要延迟执行的任务叫做延迟任务。它是由事件触发的，任务可添加，延时执行，也可取消；有别于定时任务，定时任务往往是按照固定的时间规则周期性的执行。延迟任务的使用场景很丰富，譬如：
- 红包 24 小时未被查收，需要延迟执行退还业务；
- 订单下单之后 30 分钟后，用户如果没有付钱，系统需要自动取消订单；
- 接口对接过程中因为网络等原因导致失败，1分钟后重试，直到成功，当然失败次数达阈值后取消重试
为何要自研
Java API 实现延迟任务
优势：单机版，实现简单，
弊端：没办法做成一个通用组件，满足不了大型复杂的业务场景，无法高可用，另外此种方式能添加及消费任务但是无法友好的取消任务。
Redis 实现延迟任务
优势：redis本身是一个通用的组件，现在开发一个系统基本也离不开它，用它来实现非常的方便，在一定的数据量下性能比较高
弊端：redis的zset既要完成去重，排序，又要承担着任务元素的添加，消费，移除等工作，在大型复杂的业务场景下，一旦缓存的数据量太大，性能和业务完整性无法保证。另外使用redis也无法做到保留任务的历史数据，如果基于它自身的持久化机制对性能上又有损耗
MQ 实现延迟任务
优势：方案成熟，性能和可靠性上有保证
弊端：如果专门开启一个 MQ中间件来执行延迟任务，就有点杀鸡用宰牛刀般的奢侈了，除非系统已经有MQ环境了；另外使用MQ同样无法友好的取消任务，也无法保留任务的历史数据
定时任务框架实现延迟任务
使用一些定时任务框架譬如：springTask,Quartz，这些都是功能比较强大的任务调度工具，可实现复杂
的调度功能
优势：不用去考虑实现的细节，套用框架即可，各方面细节都有所保证
弊端：对应用有一定侵入性，需要承担框架带来的维护成本，框架隐藏了实现的细节虽然方便但也为性能调优工作带来了困难。其次这些框架更适合去做定时任务。
架构设计
当其他系统或组件调用延迟任务系统的任务接口时：
1：任务数据会入库
2：根据任务的执行时间判断，如果任务需要被立即消费，则添加到当前消费队列，由消费端即时消费
3：如果任务是在未来2分钟内需要执行，则添加到未来数据集合，集合中的数据会根据任务的执行时间进行排序
4：如果任务是在未来2分钟外才执行的，数据只需暂时入库
5：使用一个定时任务实时的将未来数据集合中当前需要执行的任务数据刷新到当前消费者队列
6：使用一个定时任务每隔2分钟将数据库中未来2分钟内需要执行的数据预加载到未来数据集合中去进行排序等待
7：预加载的时间支持可配置
8：在redis中不论是未来数据集合zset还是当前消费者队列List我们需要按照任务的类型和优先级进行分组，减轻单一数据结构的压力，如下图：
8：将延迟任务系统组件改造成一个服务，采用SpringCloud体系技术，注册中心采用consul，同时采用它作为配置中心，支持配置数据的动态刷新，改造成一个服务后对外只需暴露出任务对应的feign接口即可，其他系统接入使用非常的方便。