系统设计，如何设计一个秒杀功能

需要解决的问题

1. 瞬时流量的承接
2. 防止超卖
3. 预防黑产
4. 避免对正常服务的影响
5. 兜底方法

前端设计

• 利用 CDN 缓存静态资源，减轻服务器的压力
• 在前端随机限流
• 按钮防抖，防止用户重复点击

后端设计

• Nginx 做统一接入，进行负载均衡与限流
• 用 sentinel 等进行业务端限流
• 服务拆分，将秒杀功能拆分为独立的服务，避免对现有服务产生影响
• 秒杀数据的缓存，使用分布式缓存或本地缓存方案，需要缓存预热
• 精准地库存扣减，防止超卖
• 风控识别黑产，需要动态黑名单
• 设置验证码防止脚本秒杀
• 幂等设计，防止重复下单
• 兜底方案，如果服务压力过大或者代码有漏洞，直接关闭秒杀及时止损

业务手段

通过预约、预售等方式避免秒杀的高并发流量。

详细分析

一、瞬时流量的承接

1、 秒杀活动即将开始时，用户会不断刷新页面，前端资源的访问也会消耗大量的资源。可以把这部分压力给到 CDN 厂商。

2、 秒杀的大部分请求都是无效的，可以在前端设置随机限流，使部分请求直接返回失败。

3、 对于发出的请求再次通过 lvs、nginx、sentinel 层层限流。

4、 打到后端服务后可以利用分布式缓存（Redis）或本地缓存（Caffeine）承接读写。

二、库存扣减

库存扣减需要防止并发导致的超卖。常用的是通过乐观锁解决问题：

update items set num = num - 1 where id = 1 and num > 0;

使用这个语句会产生热点行问题，压测下性能不高。优化方式如下：

1. 数据库补丁优化。可以使用阿里云的 RDS，结合 Inventory Hint 单行热点更新性能可达 3.1 万 TPS。原理简单来说就是会把相同行的修改请求分为一组，仅组内第一条语句需要抢锁，后续语句直接修改即可，不需要再次查询，仅需一次分组提交事务即可。
2. 库存拆分。将 1000 个库存拆分成 100 个小库存，每个小库存内有 10 个库存。
3. 使用 redis + lua 脚本控制库存的扣减。redis 扣减完毕后可以通过 MQ 发送一个异步消息把数据库中的库存扣掉，实现最终一致性。如果 redis 操作成功， MQ 发送失败怎么办？ 为 MQ 设置死信队列、重试等机制； redis 扣减库存时记录日志，如果 MQ 故障则检查日志进行补偿。