今天咱们来聊聊电商系统中常见的秒杀活动。几乎每一家电商都会搞秒杀，一般在促销活动中，指定一定数量的商品用低价吸引大量用户参与，但只有少数用户能购买成功，这就是电商秒杀的套路，目的是用低价商品引入大批流量。
那对于电商系统来说，怎么设计一套既能满足日常交易，又能扛住高并发的秒杀系统，这可是程序员们重点要考虑的问题。
先说商品购买流程，大家应该都熟悉。比如一个朋友转发 9 块 9 秒杀一部手机的链接，点开首先是商品详情介绍，这是流量入口，这时大批用户会进来。如果是传统模式，肯定先调接口从库里获取商品名称、价格、详细介绍等，一旦并发量上来，问题就来了，接口和数据库可能达到瓶颈，整个页面就会卡顿。
所以商城详情页面一定要优化。网页版尽量静态化，初始化页面时尽量不调接口。实在没法静态化，页面也要做好缓存，把商品详情和介绍缓存到 Redis 里也行。还要做降级处理，防止出现击穿、雪崩等情况，这时可以读取本地缓存。另外，详情页图片多且耗资源，要把图片放到独立文件服务器上，比如 CDN ，防止拉取图片占满带宽影响页面访问。
解决了页面访问，就到秒杀环节。一般到时间点狂点秒杀按钮，一秒钟点五六下都有可能。这时不做限制，服务器网关压力大，很快就会崩溃，所以必须做好限流。限流可以做页面级的，比如限制按钮点击次数，但这远远不够，服务端也要限流，一般在网管层采用一些限流算法，比如令牌桶、漏桶等，规定时间周期放一定流量进来，其余流量直接返回网络繁忙请稍后再试。商城购买接口也要做好熔断，流量大容易出现访问失败，当访问次数达到一定阈值，就要开启熔断机制，直接拒绝所有服务，等恢复正常再重新开启。失败的流量走降级方法，提示稍后再试。这样在服务高端可用性上就不用担心，系统不会轻易被流量冲垮。
再说说商品购买环节，容易出问题的是库存扣减，比如库存十个，结果被秒杀了一百个，这可就麻烦了，老板伤心你也不好过。防止这种情况，要做好扣减环节的原子性，常见的是采用分布式锁，基于 Redis 或其他的。要是不想这么麻烦，也可以用数据库的触发器，超过库存直接拒绝，也是可以的。
