如何设计秒杀系统？

遇到的问题

  1. 高并发

单机Redis只能顶得住3-4W的 QPS
短时间大量用户访问，可能造成的缓存雪崩，缓存击穿，缓存穿透问题

  1. 超卖
  2. 恶意请求

黄牛，脚本模拟请求

  1. 链接暴露

提前往后台路径发请求

  1. 数据库

每秒上万甚至十几万的 QPS 打到数据库，基本会打挂掉，如果没有做降级、限流、熔断，别的服务一起挂，小公司可能全站 404

如何设计解决

  1. 服务单一指责

微服务的设计思想+分布式部署的方式：给秒杀也单独开一个服务，将相关业务逻辑代码放一块
分库：单独建立一个数据库
表设计：该索引的地方设置索引，建完后记得用 explain 看看 SQL 的执行计划

  1. 秒杀链接加盐

URL 动态化：通过 MD5 之类的加密算法加密随机字符串做 url，通过前端代码获取 url 后台校验才能通过

  1. Redis 集群

主从同步、读写分离，搞点哨兵，开启持久化高可用

  1. Nginx

高性能 web 服务器，负载均衡

  1. 资源静态化

把能提前放入CDN 服务器的东西放进去，秒杀时减少服务器压力

  1. 按钮控制

秒杀前置灰

  1. 限流

前端限流：点一下或两下几秒后才可以继续点，保护服务器
后端限流：卖完产品，后端也关闭后续无效请求的介入
Tip：真正的限流还会加入 Sentinel、Hystrix

  1. 库存预热

秒杀前，通过定时任务或者运维提前把商品库存加载 Redis 中，等秒杀流程结束，再异步修改库存
但是，高并发下会产生问题，需要用到 Lua

  1. Lua

类似 Redis 事务，有一定的原子性

  1. 限流&降级&熔断&隔离

限流：顶不住就挡一部分出去，但是不能说不行
降级：降级了还是被打挂了 ↓
熔断：至少不影响别的系统
隔离：快影响了别拖累兄弟们

  1. 削峰填谷

MQ，秒杀一万个，服务器挂了咋办？
业务量级达不到也没关系，以后公司体量上去了不用改代码

总结

设计题 - 图1

怎样学习获得“高并发”经验？

电商剖解

设计题 - 图2

消息队列

系统设计面试题

如何答好面试中的系统设计题？