构架稳定与可扩展的优惠券系统

每次打完滴滴, 我们都可以分享领券页面到朋友圈, 让大家一起来领券. 而领完券后, 一大堆5折券到账的感觉一定很爽(可惜现在的折扣越来越少了). 想必大家都对滴滴的优惠券影响深刻. 滴滴的用户规模如此之大, 送券力度如此之高, 如果由我们来做,该如何构架这样一个稳定且有扩展性的系统呢?

可扩展的定义

我们这里主要考虑这两个方面的扩展:

1. 业务扩展
   变更或新增业务逻辑时, 尽量对已有的核心模块影响最小,保证系统整体的稳定性.

2. 性能扩展
   保证系统是可以水平扩展的, 从而具有应对更高的负载能力.

一个系统的稳定性,除了需要由健壮的代码来保证外, 架构上的拆分,也会有相当大的影响.
比如:我们将易变的模块(需求变化频繁)和稳定的模块糅合在一起部署的话, 易变模块的变化造成整个系统频繁的部署,就会对整个系统带来极大的风险.
所以扩展性在系统设计之初就需要着重考虑.

功能和性能需求:

抛开具体业务的架构都是耍流氓, 那我们先从功能和性能需求上对要做的优惠券系统有个整体上的认识, 来看看哪些需求是易变的,哪些需求是稳定的.

优惠券的生命周期

优惠券作为在线交易系统(电商,O2O)的一种重要营销手段, 每张优惠券的生命周期都由两个阶段组成:

• 发券
  可以由运营创建一个优惠券活动, 让用户主动领券, 也可以由运营对指定范围内的用户批量发券.

• 用券
  消费者收到优惠券后,在结算页从优惠券列表中选择优惠券并使用.

发券

优惠券活动管理

运营人员根据促销档期和财务计划, 制定优惠券活动的方案,包括:

1. 发券方式: 用户主动领取还是被动接收

2. 发券内容: 发券的种类, 发券数量, 是否多种券组合发放.

3. 促销方式: 见下文

4. 使用限制: 见下文

5. 通知方式: 短信通知,邮件通知,app通知

优惠券发券

从瞬时单次发券的用户数量来看, 发券活动分为:

1. 对单用户发券:
   用户大促抽奖领券,新用户注册领券,订单完成后返券以及对投诉用户补偿券时会采用这种领券活动.

   • 从功能上看,对单用户发券的玩法多种多样,属于易变的需求.

   • 从性能上看,单用户发券请求量较高,同时也非常强调券到账的及时性,在用户发出领券请求后,系统应当尽快将券送达账户.

2. 对多用户发券:

   • 从功能上看,在补贴大战,提升交易额以及唤醒沉睡的老用户时会采用,一般会结合短信通知和邮件通知的方式来让用户知晓有券到账. 多用户发券的业务较为稳定,一般是运营人员通过后台选择特定范围内用户列表后触发.

   • 从性能上看,对多用户发券的请求量较小,但发券量比较大,可能一次发放上百万张券到用户,所以多用户发券更强调发券系统的稳定性.

用券

促销方式

从券的促销方式来看, 优惠券种类一般有:

1. 立减:
   优惠金额固定的优惠券, 比如滴滴的现金券.

2. 折扣:
   优惠金额跟订单金额成比例的优惠券, 比如滴滴的折扣券.

3. 其他促销

不同的优惠券促销方式, 会对应不同的优惠金额计算逻辑.

使用限制

从用户使用角度看, 优惠券还会有多种使用限制:

1. 限时间:
   优惠券的有效期

2. 限平台
   比如设定一种券只能在微信h5平台上使用

3. 限地域
   比如只能在上海使用该优惠券

4. 其他限制

限制逻辑保证了优惠券促销花的钱,都用到了提升对应维度的运营数据上.

需求总结:

• 易变的需求:

  • 对单用户发券的方式(请求量大)

• 稳定的需求:

  • 发券活动管理(请求量小)

  • 对多用户发券的方式(请求量小)

  • 优惠券的促销方式

  • 优惠券的使用限制

架构实现

整体架构

根据功能与性能需求,我们对优惠券系统模块做以下划分:

• 优惠券发券平台
  发券系统作为核心系统,需要应对极大的访问量. 服务需要水平扩展,必须使其成为无状态, 因此服务的状态数据存储在Redis中.发券系统提供以下API:

  • 活动管理API

  • 批量发券API

  • 单用户发券API
    将单用户发券API和批量发券API拆分是因为两个接口的使用场景不太一样:批量发券的发券量非常大,但时效性要求不高, 可以做更多的优化.

  • 查询优惠券API
    提供查询所有优惠券和查询计算页可用优惠券的功能

  • 用券API

• 优惠券活动平台
  提供运营人员管理优惠后台, 给用户抽奖领券的功能.其子模块属于易变的模块, 所以用子系统单独部署的方式对系统整体稳定性更高.子系统包括:

  • 活动管理

  • 批量发放后台

  • 领券子系统(抽奖)

  • 领券子系统(注册返券)

  • 领券子系统(订单返券)

• 优惠券数据统计平台
  通过读取线上优惠券数据的备份,进行数据报表生成的平台, 提供运营数据分析是使用, 后续不再做介绍.

领券子系统都依赖于优惠券发券平台的单用户发券接口,属于优惠券上层业务子系统. 将上层业务子系统跟发券核心系统分离,可以在保证发券系统稳定性的前提下, 通过提供单用户发券API, 来更灵活的实现多种发券活动业务,比如我们可以轻松的构建一个领券子系统: 兑换码, 来实现用户线下扫码兑换优惠券的功能.

技术实现

使用券池预生成优惠券

如何保证优惠券不超发?

运营人员创建优惠券活动时, 会设定本次活动可发优惠券数量.对于用户主动领券的活动,当该活动的优惠券被领完后,用户无法再次领取改活动的优惠券. 要保证优惠券不超发,有两种方案:

1. 通过全局计数器的方式,保证并发下发券的数量变更的原子性.

2. 通过先预生成优惠券存放到队列来实现.用户领券时从队列pop取出优惠券,再和用户进行绑定完成发券操作.当队列pop不到优惠券时,就代表优惠券发完了.

如何解决优惠券唯一码的生成问题?

优惠券会有一个根据指定规则生成的全局唯一码作为交换ID, 在优惠券各个子系统中传递.比如:
XXYYZZ-20171016-001234567
XXYYZZ前缀代表业务码
中间20171016为时间
后缀001234567代表当前码的生成数量

如果我们在用户主动领券时才生成唯一码, 会存在多节点,多线程并发的问题,导致序号重复生成.一般需要加锁处理,会降低系统的性能.解决这个问题,我们可以使用预生成的方式,在单节点单线程中生成唯一码,再存入Redis队列中提供后续pop使用,从而避免加锁带来的性能下降.

结合以上两个问题, 我们采用Redis队列作为存放预生成的优惠券的券池.可以极大的提升系统的性能和稳定性.

如何应对大量的发券的请求

当优惠券活动开始时, 用户的领券操作会修改数据.当用户在结算页使用优惠券时,查询完优惠券后,会马上使用优惠券. 所以整个流程优惠券数据的读写比操作接近1:1.
常规的缓存策略为:

• 用户的所有优惠券为读缓存

• 在优惠券被写入时, 失效用户的所有优惠券缓存.

• 当用户优惠券缓存不存在时重新从数据库加载所有缓存.

这种缓存策略虽然简单,但实际应用中缓存命中率非常低.因为大多数场景都是用户领完券后立即使用.

另外用户的发券操作会涉及到写数据库,大量的写请求会造成数据库的瓶颈. 要提高系统性能.就必须使用写缓存, 即:

• 当用户写入优惠券时,先不写入数据库,直接写入集中式缓存Redis,

• 所有查询操作都直接从Redis中查询.

• Redis中的新数据通过指定数量的线程, 源源不断的同步到数据库.

整个过程如图所示: