【Java主流电商秒杀方案】百万qps秒杀方案简述（文字版配代码、视频详解）20w商品,100W预约，前后端如何处理（令牌桶，redis 分片，商品分片，分布式锁，配置中心 Apollo、Nacos）_java简历大型电商项目qps 用户量和订单量

1. 需要解决的问题

1. 高并发，重复刷接口 对服务器的负载冲击
2. 高并发，带来的超卖，需要控制商品数量
3. 高负载 下单速度和成功率的保障
1
2
3

2. 正常秒杀流程

1. 等待抢购（正常提前1周）
2. 预约
3. 等待抢购
4. 抢购
1
2
3
4

3 秒杀商品规模 预计预约人数（20W商品，预约100W人）

20个实例
1

4 主流秒杀方案

4.1 针对预约人数过多，如何降低抢购时的压力

通过给预约用户提前发放token，20w的库存，发30w个token
把token放在用户cookie中
1.有token的参与秒杀，
2. 没有token的看单机动画	（抢购中...没有抢购成功）
1
2
3
4

4.2 对于反复提交抢购，刷新的用户，过滤重复请求，可以通过限流

4.2.1 对于抢购一开始，弄到实际下单接口地址的用户，网关限流 （微服务 Gateway）可以处理

4.2.2 通过黑名单（大数据统计），过滤请求

对于重复请求限流，可以同redis集群 （redis计数器,漏桶，令牌桶），（分片，二级缓存）
1

限流工具类RateLimiter
1

服务治理---限流（令牌桶算法）

可以通过nginx限制
1
2
3

4.2.3 没有token（预约的时候分配到cookie的token）的请求，限制

4.3 后端处理100w请求

1. 100w的请求到服务器，尽快处理前面的商品，20w的商品
2. 网关过滤剩下80w的请求，可以通过令牌桶
3. 20个网关，每个服务实例处理5w的请求，分配1.5w的令牌，同时分配1w的商品库存
4. 每个tomcat做到1000-2000的qps响应
5. 每个网关开1.5w个令牌桶，总共20个实例，实际发放30w个令牌，得不到令牌的直接返回失败，耗时比较短，不会到下单流程
6. 大部分请求被拒绝，剩余的进入下单消息队列
1
2
3
4
5
6

4.4 如何快速生成订单，并响应用户

1. 数据库1秒2000的写入，比较难，集群也只能达到10000
2. 下单请求可以把订单商品，订单信息，下到redis里面
3. 考虑到redis压力，可以对不同用户的订单下单到不同的redis里面（分片）
4. 订单放在redis目的：
4.1 速度快
4.2 用户下单后正常会不停的查询下单是否成功，可以作为订单查询使用
1
2
3
4
5
6

4.5 如何解决耗时的入库操作

1. 后端数据库正式写入，
2. 通过消息队列，流量削峰，
3. 让后端消费消息，入库（执行耗时的入库操作，分布式事务）
4. 入库完成后，可以把redis的订单信息删除
1
2
3
4

5. 如何控制不超卖 20w商品，30w令牌（20个实例，每个实例1.5w个令牌,平均1w的商品库存）

5.1 分布式锁-Redission 分析

Redission是 封装好的分布式锁的方案，可以对商品id加锁
如果商品数量几千个，还行
加锁，解锁，一次5-10ms
平均1秒100多单
几十万次，时间开销很大
性能问题
所以针对20w商品，需要对	商品数量 分片
1个分布式锁 500个商品数量
商品id10 goodsId-10-1/goodsId-10-2/goodsId-10-3 500个
通过hash放到不同的key上面
如果redis压力比较大，redis再做集群（主从）
比较难以控制不同key余量的消耗
总结下来这种方案“太复杂” 
1
2
3
4
5
6
7
8
9
10
11
12
13

5.2 通过配置中心，提前把20w库存的商品，分配到20个实例里面

在服务器实例直接写好商品的数量，不需要走redis,不需要通信，效率比较高
20w的商品
通过配置中心，下发每个实例商品的数量，动态控制
抢购开始，下发每个服务10000的商品数量
当这个实例将内存的商品数量消耗完成的时候，卖完了
1
2
3
4
5

5.2.1微服务配置中心 Apollo、Disconf、Spring Cloud Config、Nacos

微服务配置中心的技术选型一般有以下几个：Apollo、Disconf、Spring Cloud Config、Nacos等
Apollo(携程开源)
nacos(阿里开源)
Spring Cloud Config(Spring Cloud 全家桶成员）
【配置中心概念】
配置中心最基础的功能就是存储一个键值对，用户发布一个配置（configKey），然后客户端获取这个配置项（configValue）。
配置中心的功能就是当某个配置项发生变更时，不停机就可以动态刷新服务内部的配置项
1
2
3
4
5
6
7

5.2.2 如何处理 由于服务的处理速度和请求不均匀，导致有些实例早就卖完了，其他的还有大量商品剩余的情况

抢购的过程中，服务挂了，可以暂时先不管，结果就是少卖出去一些
后面出了方法：等所有的卖光了，剩余7000个，再启动卖
也可以等超过30分钟后，和没付款的，订单取消，一起丢到库存池再卖
1
2
3

6.下面进入实际的秒杀方案

6.1 技术点介绍：

前端：Thymeleaf,Bootstrap,Jquerry
后端：SpringBoot,MybatisPlus,Lombok
中间件：RabbitMQ,Redis
1
2
3

6.2 秒杀方案：

分布式会话：用户登录，共享session
功能开发：商品列表，商品详情，秒杀，订单详情
系统压测：JMeter入门，yace
页面优化：页面缓存，url缓存，对象缓存，静态化，前后端分离
服务优化：RabbitMQ消息队列，接口优化，分布式锁
安全优化：隐藏秒杀地址，算术验证码，接口限流。
1
2
3
4
5
6

6.3 文字版课程

慕课网,乐字节 Java电商秒杀项目

6.4Bilibili 视频版课程

【电商秒杀系统项目实战_找工作涨薪必备】承载双11秒杀亿级流量的java项目_做完该项目让你瞬间让你搞懂多线程