社区
Java SE
帖子详情
电商网站中常见的秒杀是怎么实现的?
若鱼1919
2018-01-17 08:41:25
电商网站中常见的秒杀是怎么实现的?
...全文
2030
5
打赏
收藏
电商网站中常见的秒杀是怎么实现的?
电商网站中常见的秒杀是怎么实现的?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
5 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
若鱼1919
2018-02-05
打赏
举报
回复
https://github.com/xjs1919/miaosha
秒杀与其他业务最大的区别在于:秒杀的瞬间,(1)系统的并发量会非常的大(2)并发量大的同时,网络的流量也会瞬间变大。 关于(2),最常用的办法就是做页面静态化,也就是常说的前后端分离,把静态页面直接缓存到用户的浏览器端,所需要的数据从服务端接口动态获取。这样会大大节省网络的流量,再加上CDN,一般不会有大问题。 关于(1),这里的核心问题就在于如何在大并发的情况下能保证DB能扛得住压力,因为大并发的瓶颈在于DB。如果说请求直接从前端透传到DB,显然,DB是无法承受几十万上百万甚至上千万的并发量的。所以,我们能做的只能是减少对DB的访问,前端发出了100万个请求,通过我们的处理,最终只有10个会访问DB,这样就可以了!针对秒杀这种场景,因为秒杀商品的数量是有限的,这种做法刚好适用! 那么具体是如何来减少DB的访问呢? 假如:某个商品可秒杀的数量是10,那么在秒杀活动开始之前,把商品的ID和数量加载到缓存,比如:Redis。服务端收到请求的时候,首先减一下Redis里面的数量,如果数量减到0随后的访问直接返回秒杀失败。也就是说,只有10个请求最终会去实际的请求DB。 当然,如果我们的商品数比较多,1万件商品参与秒杀,1万*10=10万个并发去请求DB,DB的压力还是会很大,这里就用到另一个非常重要的组件:消息队列。我们不是把请求直接去访问DB,而是先把请求写到消息队列,做一个缓存,然后再去慢慢的更新数据库。这样做以后,前端用户的请求可能不会立即得到响应是成功还是失败,很可能得到的是一个排队中的返回值,这个时候,需要客户端再去服务端轮询,因为我们不能保证一定就秒杀成功了。当服务端出队,生成订单以后,把用户ID和商品ID写到缓存中,来应对客户端的轮询就可以了。 这样处理以后,我们的应用是可以很简单的进行分布式横向扩展的,以应对更大的并发。 当然,秒杀系统还有很多要处理的事情:比如防刷限流、比如分布式Session等等。具体的细节可以看视频:猛戳这里
若鱼1919
2018-01-17
打赏
举报
回复
这个说的好像在理啊
自由自在_Yu
2018-01-17
打赏
举报
回复
https://www.2cto.com/kf/201701/587008.html
oyljerry
2018-01-17
打赏
举报
回复
分布式锁。来维护计数等。一般可以用redis等
电商
秒杀
系统的设计与
实现
.pdf
电商
秒杀
系统的设计与
实现
.pdf
Java
实现
电商
秒杀
项目
电商
秒杀
项目设计方案 项目启动时将商品库存信息缓存到redis 当前用户
秒杀
商品时,首先去redis查询用户是否
秒杀
商品,没
秒杀
过,再去数据库查询,若该用户已
秒杀
过商品则不能,在参与
秒杀
同样商品。 若用户没有参与...
电商网站
高并发
秒杀
实战
这是一个电商平台的项目实战案例,基于双11抢购活动真实需求设计,从需求分析到框架设计,从用户登录到抢购商品、完成支付等,这其
中
涉及千万级用户如何
实现
有序队列、如何进行高并发测试、用户唯一性判断等,该案例...
电商
秒杀
系统的设计与
实现
.zip
电商
秒杀
系统的设计与
实现
Java性能优化亿级流量
秒杀
解决方案及电商项目
秒杀
实现
(7.25G)
Day1:
秒杀
场景及优化核心知识.rar;c Day2:高性能
秒杀
方案框架解读.rar Day3:性能及压力测试.rar Day4:分布式服务器部署.rar Day5:缓存方案及接入实操.rar Day6:静态化及cdn部署.rar'q#Y:a9K%d)W0-0M'p!f Day7:缓存与...
Java SE
62,612
社区成员
307,332
社区内容
发帖
与我相关
我的任务
Java SE
Java 2 Standard Edition
复制链接
扫一扫
分享
社区描述
Java 2 Standard Edition
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章