点击上方"IT牧场",选择"设为星标"技术干货每日送达!
来源:github.com/coderliguoqing/distributed-seckill/
分析,在做秒杀系统的设计之初,一直在思考如何去设计这个秒杀系统,使之在现有的技术基础和认知范围内,能够做到最好;同时也能充分的利用公司现有的中间件来完成系统的实现。
我们都知道,正常去实现一个WEB端的秒杀系统,前端的处理和后端的处理一样重要;前端一般会做CDN,后端一般会做分布式部署,限流,性能优化等等一系列的操作,并完成一些网络的优化,比如IDC多线路(电信、联通、移动)的接入,带宽的升级等等。而由于目前系统前端是基于微信小程序,所以关于前端部分的优化就尽可能都是在代码中完成,CDN这一步就可以免了;
通过分布式锁的方式控制最终库存不超卖,并控制最终能够进入到下单环节的订单,入到队列中慢慢去消费下单
请求进来之后,通过活动开始判断和重复秒杀判断之后,即进入到消息队列,然后在消息的消费端去做库存判断等操作,通过消息队列达到削峰的操作
其实,我觉得两种方案都是可以的,只是具体用在什么样的场景;原有方案更适合流量相对较小的平台,而且整个流程也会更加简单;而新增方案则是许多超大型平台采用的方案,通过消息队列达到削峰的目的;而这两种方案都加了真实能进入的请求限制,通过redis的原子自增来记录请求数,当请求量达到库存的n倍时,后面再进入的请求,则直接返回活动太火爆的提示;
后端项目是基于SpringCloud+SpringBoot搭建的微服务框架架构
前端在微信小程序商城上
SpringCloud zuul的层面有很好的限流策略,可以防止同一用户的恶意请求行为
1 zuul:
2 ratelimit:
3 key-prefix: your-prefix #对应用来标识请求的key的前缀
4 enabled: true
5 repository: REDIS #对应存储类型(用来存储统计信息)
6 behind-proxy: true #代理之后
7 default-policy: #可选 - 针对所有的路由配置的策略,除非特别配置了policies
8 limit: 10 #可选 - 每个刷新时间窗口对应的请求数量限制
9 quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制(秒)
10 refresh-interval: 60 # 刷新时间窗口的时间,默认值 (秒)
11 type: #可选 限流方式
12 - user
13 - origin
14 - url
15 policies:
16 myServiceId: #特定的路由
17 limit: 10 #可选- 每个刷新时间窗口对应的请求数量限制
18 quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制(秒)
19 refresh-interval: 60 # 刷新时间窗口的时间,默认值 (秒)
20 type: #可选 限流方式
21 - user
22 - origin
23 - url
当一个活动的访问量级特别大的时候,可能从域名分发进来的nginx就算是做了高可用,但实际上最终还是单机在线,始终敌不过超大流量的压力时,我们可以考虑域名的多IP映射。也就是说同一个域名下面映射多个外网的IP,再映射到DMZ的多组高可用的nginx服务上,nginx再配置可用的应用服务集群来减缓压力;
这里也顺带介绍redis可以采用redis cluster的分布式实现方案,同时springcloud hystrix 也能有服务容错的效果;
而关于nginx、springboot的tomcat、zuul等一系列参数优化操作对于性能的访问提升也是至关重要;
补充说明一点,即使前端是基于小程序实现,但是活动相关的图片资源都放在自己的云盘服务上,所以活动前活动相关的图片资源上传CDN也是至关重要,否则哪怕是你IDC有1G的流量带宽,也会分分钟被吃完;
干货分享最近将个人学习笔记整理成册,使用PDF分享。关注我,回复如下代码,即可获得百度盘地址,无套路领取!•001:《Java并发与高并发解决方案》学习笔记;•002:《深入JVM内核——原理、诊断与优化》学习笔记;•003:《Java面试宝典》•004:《Docker开源书》•005:《Kubernetes开源书》•006:《DDD速成(领域驱动设计速成)》•007:全部•008:加技术讨论群近期热文•不同场景下,如何选择数据库?•MySQL使用规范手册,程序员必知必会•Redis是如何实现点赞、取消点赞的?•万亿条数据查询如何做到毫秒级响应?•数据库分库分表思路•优秀的Java程序员必须了解的GC哪些想知道更多?长按/扫码关注我吧↓↓↓>>>技术讨论群<<<喜欢就点个"在看"呗^_^