从零开始设计开发优惠券系统（三）

本篇文章主要讲解下优惠券系统是如何做到高并发、高可用的

对于优惠券系统来看，有两个地方，流量和并发比较高

• 一个是领券

  如果出现了性价比很高的神券，限制事件段，那么在开放领券的一瞬间，很高的并发会使得优惠券压力非常大，如果优化好领券的性能，对于用户来说是非常影响体验的

• 另一个是查询优惠券

  1）在用户打开app的时候，就会请求优惠券系统，有哪些可以领取的活动券，这些券是不限制任何场景的，任何人都能领取

  2）在用户点击商品详情页的时候，也会请求优惠券系统，有哪些优惠券被此商品命中了，而且用户点击进入商详页是进入app后最频繁的操作，对于优惠券的系统压力也是很大的

  3）在用户点击进入提交订单页面后，系统会自动匹配好一套最优惠的叠加优惠券组合，包括了商品券、运费券等，此时需要我们有一系列的规则，去保证用户使用的是最优的券

  4）用户领取或者使用优惠券后，用户点击我的账户，去查询我的优惠券信息，此时，查询的请求一般不会太多，但是用户领取券或者使用、核销券的记录非常多，如何能在最短的时间给用户返回数据，也是架构方面需要考虑的事情

本篇文章主要讲查询，因为查询的场景比较丰富，性能优化处理的方式也更加多样。领券放在下个文章

APP登录页面展示

首先，我们有活动的概念，我们会有活动页，为了吸引客户的眼睛，一般都是一些促销力度比较大的商品，这些商品活动页，变更的频率不会太勤，可能几个小时不会发生变化，其实针对于固定的活动页来看，对应的优惠券也是固定的，那么我们可以专门将活动页的信息和优惠券的信息进行绑定，打开活动页的时候，直接通过配置的优惠券id（或者加密等信息）来查询优惠券系统，给出对应的返回，达到展示的目的

这一部分的配置能力我个人认为不属于优惠券系统的核心能力，应该归类为营销工具，或者前端app搭建一个配置系统更为合适。当然，在非常简单的，且职责划分不清晰的初期阶段，可以放到优惠券系统来做，但是后期一定要拆分出去的。

商品详情页查询

这个阶段是请求量最大的一个阶段，涉及到的数据也是当前生效的所有数据。

首先第一步，我们要确定好当前生效的所有优惠券的数据范围，可能我们优惠券系统当前共有10000条数据，但是当前的时间点上，生效的只有1000个活动，每个活动下有二个批次，那么当前生效的优惠券数据就有2000条。这些数据算是优惠券系统的热点数据。需要放到jvm里边去的，缓存时间不能太长，因为使用jvm是本机缓存，那么一个数据最长有可能会储存2个单位的时间长度。而且jvm当中的缓存，要存储当前及1个小时之内能生效的所有数据信息，保证对外输出数据的稳定性

第二步，要做数据的筛选，我们储存到jvm的数据一般是批次的id信息，我们需要通过id信息去获取批次的全量信息，所以，在批次审批通过的时候，我们需要把信息存储到redis当中去，然后我们根据批次的限制信息，去一个个筛选符合要求的批次信息。作为预返回的数据集

第三步，查询当前用户是否领取过该张优惠券信息，当数据量非常大了以后，即便经过了数据库分库分表，增加各种索引优化以后，我们还是不能解决数据库的瓶颈问题，这个时候需要我们将用户领取批次的记录存到分布式缓存中，一定也需要设置过期时间，设置为券的结束时间即可。我们直接就可以为这个券信息打上标记，是否领取过

第四步，排序，也是比较个性化的一步，可以按照客户端的请求来进行数据返回，也可以配置默认的返回规则，比如已经领取的排在第一位，按照门槛值依次排列，等等。

走完以上四步之后，数据可以正常返回给客户端了

最优券查询

最优券的组合一定是用户目前领取的生效状态的优惠券的子集。

首先第一步，我们要确定好当前用户是否有生效状态的优惠券，此时，一定不能从数据库直接去查询，数据库查询会有瓶颈，我们需要把用户生效的券信息储存到nosql中去，方便我们使用

第二步，数据筛选，如果有生效的优惠券，那么我们要去一步步校验，当前优惠券能不能适用这个门店、这个渠道、这个商品、这个门槛值

第三步，最优的匹配规则，什么叫最优的，一定是给客户最省钱的，首先优惠券面额最大的，排在最前，如果面额都一样，把过期时间最短的排在最前 … 等等 一系列规则，第二个，看能不能有券的叠加，商品券和平台券和运费券能叠加，从而匹配出来一套优惠券的最优组合

个人优惠券

这个阶段是请求量比较小的一个阶段，确是涉及到数据量最大的一个阶段，用户需要从领券记录的全量信息表中去查询自己的各个状态的优惠券信息，比如：1、未使用的 2、已使用的 3、已过期的

其实我们有两种类型的数据

• 一种是可以正常使用的券

  对于可以正常使用的券，我们可以考虑放到redis中去，这个券的数量不会太大，从redis获取会更加快速，体验更好

• 另一种是已经过期或者已经使用的券

  我们可以考虑换一种介质来储存领取记录，比如使用elasticSearch、mongoDb等，但是不要使用redis来存储，当数据量大了以后，redis会存在大key的问题，到时就比较难处理了

图后补，不然这个系列是写不完了