发券、短信等任务系统的设计和实现
前言：当前外卖、叫车、共享单车等市场比较火爆；各个公司为了抢占市场，不惜投入大量资金来补贴拉取用户，从而占领市场。比如美团，滴滴，摩拜等都会通过各种各样的活动奖励来拉新以及留存用户；常用的手段就是发券，然后短信通知用户，如下图：1-1所示。那么这种任务系统的架构设计是什么样子呢，下面就做个大概介绍。
图1-1 短信通知发券
一、任务系统结构设计介绍
图2-1 任务系统设计架构
任务系统架构大的可分为四模块，如图2-1所示。第一个模块是统一对外提供服务的接口，简称“应用层”；第二个模块是任务预
处理模块，包括实时和准实时处理模块；第三个模块是数据库部分；第四个模块是封装下游的各个业务模块，简称“下游业务模块”。
下面我们将逐一介绍各个模块。
应用层。应用层是我们这个系统抽象出来之后，暴露对外提供的通用且唯一的接口，这里就体现了营销类任务系统设计原则中的
通用性。目前支持券、积分、现金、短信以及push等形式的任务，业务方不需要关注这些任务是怎么实现的，只需要按照我们提供的
协议调用接口就行。
预处理模块。我们提供了两种可接入方式，一种是实时接口，另一种是准实时接口。实时接口会在请求结束返回当前执行结果，
这种接口适应于对实时性要求非常高的任务，比方现金奖。另一种是准实时接口，只所以是准实时是因为执行完请求不会立即返回
结果，给接入方的感觉就是成功了。准实时任务我们会先入MQ队列，然后保存到数据库中，最后再通过后台异步定时脚本从数据库
中把任务取出来执行，这么做有2个好处，第一是通过MQ削峰，既然是抽象通用的任务系统，那必然会在应用层对接很多业务方，
流量自然也非常大（目前我们系统QPS可以保证打到10000左右），为了不至于因为上游的大促活动导致流量暴增从而对任务系统造
成影响，我们借助于MQ来抵挡“洪峰”。可以根据系统的QPS来设置MQ的消费速度，从而保证任务系统的稳定性。
数据库。数据库是用来保存应用层下来的任务数据，一个是为了case回放时用到，另一个是对于准实时的任务，这里保存的数
据供后续实际处理用。
下游业务模块。下游业务模块衔接任务系统和下游真正的业务方，封装下游各个业务，如发券系统，短信系统等等，然后在应
用层里新增券和短信等协议类型，应用方按照协议接入即可，简单统一。理论上这个模块可以横向无限扩展，只要有新的下游业务，
我们都可以封装然后提供给应用层。