共计 960 个字符，预计需要花费 3 分钟才能阅读完成。
我们知道秒杀类的活动对整个运营贡献是最大的，它的特点是瞬间流量俱增、请求数量远大于库存，导致保证下单扣库存准确性难度大，那我们前端、后端怎么做才能保证呢？下面是我的一些思考。
先来说说整体的设计理念，秒杀类的活动光靠水平扩展扩增机器只能是个备选方案，它的成本和收益不对等。那我们就应该尽量利用有效的资源最大化处理业务，可从限流、异步处理、内存缓存角度考虑。
接下来说说具体的落地方案。秒杀类的活动前端一般会展示商品描述、秒杀价格、已售比例、时间提示，这些内容基本上是不变的，那我们可以通过内容分发 CDN 机制来将页面静态化，减少动态元素。前端还需要减少用户提交次数，用户提交之后按钮置灰，禁止重复提交，但是别忘记了还有刷子这个灰色产业链，所以后端还需要做一些限制。
在后端的服务控制层针对同一访问 UID, 限制请求频率。或者先把请教都写到消息队列中缓存一下，逻辑层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。甚至，我们可以利用缓存来应对读写请求，首先把库存信息同步到 Redis 缓存中，所以的减库存操作都 Redis 中进行，然后同步到数据库中。实际上，这些还远远不够，我们还需要考虑以下场景。
场景一是同一个账号，一次性发出多个请求。我们可以利用 Redis 内容缓存来判断用户是否已参加过了活动，写入一个标志位，结合乐观锁特性约束只允许一个请求写成功，成功写入的也就是没有记录的才能继续参加。
场景二是多个账号，一次性发送多个请求。针对这种场景，我们通过检测指定机器 IP 请求频率可以解决，如果发现某个请求 IP 请求频率过高，可以给它弹出一个验证码或者直接禁止它的请求。
场景三是多个账号，不同 IP 发送不同的请求。这种场景下的请求，和真实用户行为基本相同，想做分辨很难，需要通过账号数据进行数据挖掘后打标，结合是否经常抢票、退票等等标识为风控用户。
其实秒杀类的活动最大的挑战是如何保证高并发下的数据安全和防刷，这是一个矛与盾的博弈。总结一下今天的文章重点，针对秒杀系统，尽量将请求拦截在系统上游，越上游越好，另外读多写少的多使用缓存。好，今天的分享就到这里，欢迎分享给你的朋友。
文章来源：www.liangsonghua.me
作者介绍：京东资深工程师 - 梁松华，在稳定性保障、敏捷开发、JAVA 高级、微服务架构方面有深入的理解
