赞
踩
特点:
1)时间短、瞬间访问量大
2)读多写少的场景。(库存固定则写操作固定,但访问量肯定无限大)
难点:
1)库存只有一份,但大量用户在集中时间对该数据进行读写。
2)秒杀系统之所以挂,是因为请求没有经过上游的过滤与拦截,直接压倒在下游的数据层。
常见的 Java Web 架构:
核心思想:尽量将请求拦截在系统上游;读多写少的场景使用缓存
介绍一些常见的操作:
1)浏览器端的拦截
2)站点层的拦截
3)服务层的拦截
4)其他
当然这里并没有完全实现
PS:
瓶颈分析
从业务角度分析,高并发主要发生在秒杀商品详情页。进入秒杀商品详情页以及请求涉及到的操作有:
1)加载网页资源
2)获取服务器时间的请求
3)获取秒杀地址的请求
4)执行秒杀的请求
结论:
优化方案
1)浏览器端采用的拦截
a. 不提前暴露秒杀地址,以及增加 md5 不让用户提前猜到秒杀地址。避免使用机器秒杀
b. 商品详情页静态化。
2)Web层采用的拦截
a. 页面静态化
b. 将静态文件存放到 CDN。【本项目并没有实现】
3)Service层的优化
a. Redis 缓存商品信息,并设置超时时间来维护数据一致性
b. Redis 缓存商品库存,并利用 Redis 事务和 lua 脚本完成写请求。【本项目并没有实现】
4)数据库层的优化
a. 使用 MySQL 的存储过程,减少服务器端和数据库端通信次数,从而降低网络延迟和GC时间。
URL | 解释 |
---|---|
/list | 秒杀商品列表页 |
/{seckillId}/detail | 获取商品的秒杀地址,主要工作内容是生成md5。 |
/{seckillId}/{md5}/execution | 执行秒杀 |
/time/now | 获取服务器时间 |
PS:
秒杀商品列表页
秒杀商品详情页-三种状态
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。