秒杀抢红包实战系列（一）抢红包场景介绍

在IT行业，对于ToC的业务来说算是比较复杂的，特别是一些社交、商城等场景动不动就会存在高并发的功能点。所以咱们在做系统的时候一定要充分的考虑到实际的使用场景，而不要只做所谓的curd的工作。对于这两年IT行业的环境来说，失业的人越来越多，但是企业也越来越难招人的。像我们比如发一个招聘jd出去的话，说实话一上午确实能收到5、6十份简历，但是细看的话，真正能过筛选的都比较少，为什么呢？以我的经历来看，大部分员工都只会crud的工作。在面试的时候，考察实际场景相关的内容的时候，大部分人都是死记硬背的，一问到细节部分就没下文了。所以这也是大家需要注意的地方。

昨天晚上在群里有个小伙伴准备做抢红包相关的场景，然后一部分同学陪着她梳理了整个的流程。所以今日的话，我们来编写一个系列专门介绍下抢红包的场景。

抢红包目前在社交场景里面使用是最频繁的，不管是传统的IM聊天社交还是现在的直播社交，IM聊天的场景里面主要是红包，直播场景的话，有涉及到红包或者福袋的概念。但是其实无外乎都是一个高并发秒杀的场景。所以我们来剖析下这个抢红包的概念。

目前抢红包的整个流程主要分为3个部分，分别是：

1、创建红包
2、抢红包
3、查看抢红包的记录

这3个部分直接提现了整个抢红包的流程。我们以微信红包来举例分析下这个场景。

1）人数众多

目前每一个微信的群里面的人数上限是500人，假设张三发了一个红包，此时如果群里所有人在线的话，那么同时最高能达到的并发数是每秒500。想象一下，假设同一秒钟有几百个，几千个，几万个，几十万个群发了红包，大家想象下此时的并发量得多大。

2）响应要求很快

大家在抢红包的时候，当触发点击的时候，需要马上把抢到的红包的信息给展示出来。所以要求的是后端响应非常快，不能出现阻塞。不能让用户一直在那等着。

3）金额要计算准确

所有随机个数的红包总额加起来必须要等于发的红包总金额，不能出现少金额，也不能出现多金额的问题。

4）需要有完整的红包获取记录

每一个红包的获取明细记录都需要进行记录。并且提供给用户查看。

所以对于红包来说，相关的挑战性还是比较大的。我们将在接下来的系列里面挨个介绍下对应的细节。