当前位置:   article > 正文

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

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项目_做完该项目让你瞬间让你搞懂多线程

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/635976
推荐阅读
相关标签
  

闽ICP备14008679号