发券、短信等任务系统的设计和实现

前言：当前外卖、叫车、共享单车等市场比较火爆；各个公司为了抢占市场，不惜投入大量资金来补贴拉取用户，从而占领市场。比如美团，滴滴，摩拜等都会通过各种各样的活动奖励来拉新以及留存用户；常用的手段就是发券，然后短信通知用户，如下图：1-1所示。那么这种任务系统的架构设计是什么样子呢，下面就做个大概介绍。

图1-1 短信通知发券

一、任务系统结构设计介绍

图2-1 任务系统设计架构

任务系统架构大的可分为四模块，如图2-1所示。第一个模块是统一对外提供服务的接口，简称“应用层”；第二个模块是任务预

处理模块，包括实时和准实时处理模块；第三个模块是数据库部分；第四个模块是封装下游的各个业务模块，简称“下游业务模块”。

下面我们将逐一介绍各个模块。

应用层。应用层是我们这个系统抽象出来之后，暴露对外提供的通用且唯一的接口，这里就体现了营销类任务系统设计原则中的

通用性。目前支持券、积分、现金、短信以及push等形式的任务，业务方不需要关注这些任务是怎么实现的，只需要按照我们提供的

协议调用接口就行。

预处理模块。我们提供了两种可接入方式，一种是实时接口，另一种是准实时接口。实时接口会在请求结束返回当前执行结果，

这种接口适应于对实时性要求非常高的任务，比方现金奖。另一种是准实时接口，只所以是准实时是因为执行完请求不会立即返回

结果，给接入方的感觉就是成功了。准实时任务我们会先入MQ队列，然后保存到数据库中，最后再通过后台异步定时脚本从数据库

中把任务取出来执行，这么做有2个好处，第一是通过MQ削峰，既然是抽象通用的任务系统，那必然会在应用层对接很多业务方，

流量自然也非常大（目前我们系统QPS可以保证打到10000左右），为了不至于因为上游的大促活动导致流量暴增从而对任务系统造

成影响，我们借助于MQ来抵挡“洪峰”。可以根据系统的QPS来设置MQ的消费速度，从而保证任务系统的稳定性。

数据库。数据库是用来保存应用层下来的任务数据，一个是为了case回放时用到，另一个是对于准实时的任务，这里保存的数

据供后续实际处理用。

下游业务模块。下游业务模块衔接任务系统和下游真正的业务方，封装下游各个业务，如发券系统，短信系统等等，然后在应

用层里新增券和短信等协议类型，应用方按照协议接入即可，简单统一。理论上这个模块可以横向无限扩展，只要有新的下游业务，

我们都可以封装然后提供给应用层。

二、任务系统应用层协议定义

协议比较简单，如图2-2所示。type表示需要执行的任务类型，每种类型是一个数组，所需要的参数也不同（依赖下游模块），应用层用户根据任务系统给定的协议接入，支持执行多个任务，比方发券+短信，任务系统会按照顺序有序的执行,先执行数组中第一个数组任务，执行成功再执行第二个，依次类推，如果有一个执行失败，后面的将不会再执行。而且，我们还有重试机制，比方其中一个任务执行失败，我们会按照一定方法重试，直至达到某一个阈值之后将不再重试。

图2-2 任务系统类型协议