《高并发红包炸弹项目性能优化》系列一:项目介绍

一、项目介绍

​ 受疫情影响,公司打算在今年搞一次全国医生线上年会。而公司为了或是引流、或是给医生分福利,计划设计一个砸钱抢红包的环节。运气非常不错,虽然整体方案最初的设计不是我做的,但是最后此红包项目的性能优化却落到了我这里。平常的业务项目里,大多接触不到高并发场景,故借此机会,对此项目进行一个好好优化梳理,相信一定会对自己大有裨益的。

首先介绍下抢红包的流程,如下图所示:

  1. 首先是年会活动主会场界面,如下图一所示,右下角展示的就是红包炸弹,当有炸弹即将在1分钟后爆开时,就会进入此60秒倒计时。当倒计时完成时界面出现抢红包的云朵图案,如下图二所示。
  1. 当点击抢红包云朵图案时,有一下情况:

    1. 用户没有报名参加年会,是无法参与抢红包的,会提示还没报名,并引导用户去报名页面,如下图一所示;
    2. 用户点击云朵,但是没有抢到红包,提示手慢了,如下图二所示;
    3. 用户点击云朵,成功抢到了,点击开红包,查看红包明细,如下图三所示;
    4. 用户点击云朵,系统检测出来该用户今天已经成功抢到三次红包了,提示已经3连冠,把机会让给别人。如下图四所示。
    5. 用户点击云朵,系统检测出来该用户已经抢成功过了当前红包,直接进入红包明细,如下图五所示。
  1. 后台投放红包很简单,管理员可以在后台投放红包炸弹,指定什么时候炸开,投放的红包会分成多少份,总金额是多少。如下图所示:

image-20210114001141228

  1. 产品的一些关键特殊的要求,汇总如下:
    1. 一个红包炸开了,最多抢15s,这个红包就会被自动置完成,用户不能再抢了
    2. 一个用户一天最多抢成功3个红包
    3. 一个红包,同一用户最多只能抢成功一次
    4. 管理员随时可以在后台取消红包

至此,相信大家对此项目已经有了一定的基本了解。我再附上一张流程图更好的说明整个流程。

image-20210114002502394

二、难点分析

这个项目是有一定难度的,具体难在哪儿,我个人的看法如下:

  1. 公司的医生用户基数大,年会报名人数预计在30万+,年会当晚会持续多轮红包炸弹轰炸,平均QPS约为在30w/15s = 2000,但是抢红包的这15s不可能每一秒钟都qps都是均衡的,预计峰值QPS可能达到30w/5s = 6000左右,也就是预计在红包炸弹炸开的前5sQPS应该是最高的时候。查阅资料 可知,如微博每天1亿多pv的系统一般也就1500QPS,5000QPS峰值。但是具体多少QPS跟业务强相关,只读接口读缓存,将压力给到缓存单机3000+没问题,写请求1000+也正常,也复杂些可能也就几百+QPS。
  2. 如此高的并发下,我们很容易在服务层面想到加机器,但是最应该保护的其实是DB。如果一个红包分成了1000个子红包,这意味着抢完这个红包最多要写库1000次。感觉写库的量并不大,但是要知道的是,这1000次写库非常集中,瞬时写库会给DB造成比较大的压力,可能导致并发下其他查询事务受到影响,甚至影响到其他业务。故我们需要对必要的接口进行流量控制以保证接口的吞吐量维持在一个较高的位置,但是又不会直接影响到服务性能。
  3. 并发下,如何保证不“超抢”。例如其实只发了1万元红包,不能因为并发原因,就让用户抢出去2万块钱了。底线应该是,宁可让用户抢不到,也不能抢超了。
  4. 怎样避免羊毛党,恶意刷接口等操作造成公司利益受损?

三、总结

好了,到这里我们先对此项目有个整体上的感知即可。

抢红包面向医生群体,数量约30w+;抢红包需要先报名;一天最多抢成功三次;同一红包只能抢成功一次。

下一篇文章具体介绍下这个项目的数据库表设计,以及他们的接口代码实现。