秒杀系统

本文介绍了秒杀系统面临的技术挑战及解决策略,包括系统独立部署、页面静态化、使用CDN缓存、JavaScript控制购买按钮状态等。同时,还提出了采用乐观锁避免超卖、使用验证码防止秒杀器等措施,并详细阐述了前端、站点和服务层的设计方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

秒杀系统:
1. 秒杀技术挑战
   1)对现有网站业务造成冲击,解决方案:将秒杀系统独立部署,甚至使用独立域名,使其与网站完全隔离。
   2)高并发下的应用会对应用服务器和数据库服务器造成负载压力,解决方案:重新设计秒杀商品页面,不使用网站原来的商品详细页面,页面内容静态化
   3)突然增加的网络及服务器带宽,解决方案:和运营商重新购买或者租借服务器,将秒杀商品页面缓存在CDN
   4)如何控制秒杀商品页面购买按钮的点亮购,解决方案:使用JavaScript脚本控制,加上随机版本号,每次浏览器刷新都访问JavaScript文件服务器
   5)如何只允许第一个提交的订单被发送到订单子系统,解决方案:虑通过cookie的方式来应对,符合一致性原则
   6)库存会带来“超卖”的问题:售出数量多于库存数量,解决方案:采用乐观锁
   7)使用验证码应对秒杀器

2. 秒杀架构原则
    1)尽量将请求拦截在系统上游传统
    2)读多写少的常用多使用缓存

3.秒杀架构设计
   1)前端层设计:
      (1)页面静态化,页面上各类静态资源分开存放,然后放到cdn节点上分散压力;
      (2)倒计时出于性能原因一般由js调用客户端本地时间,客户端与服务器时钟不一致可以采用客户端定时和服务器同步时间;    
      (3)浏览器层请求拦截,用户点击“查询”或“购票”后,按钮置灰,禁止用户重复提交请求,限制用户 在x秒之内只能提交一次请求;
   2)站点层设计:
      (1)同一个uid,限制访问频度,做页面缓存,x秒内到达站点层的请求,均返回同一页面
      (2)同一个item的查询限制访问频度
   3)服务层设计:
      (1)对于写请求,做请求队列,每次只透过有限的写请求去数据层,如果均成功再放下一批,如果库存不够则队列里的写请求全部返回“已售完”;
      (2)对于读请求,cache来抗,不管是memcached还是redis,单机抗个每秒10w应该都是没什么问题的;
               用户请求分发模块:cdn分发,dns轮询,使用Nginx或Apache将用户的请求分发到不同的机器上
       并发队列的选择:Java的并发包提供了三个常用的并发队列实现,分别是:ConcurrentLinkedQueue 、 LinkedBlockingQueue 和 ArrayBlockingQueue;由于我们的系统入队需求要远大于出队需求,一般不会出现队空的情况,所以我们可以选择ConcurrentLinkedQueue来作为我们的请求队列实现
 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值