商城系统秒杀功能设计思想

业务特点

1、瞬时并发量大,秒杀时会有大量用户在同一时间进行抢购,瞬时并发访问量突增几倍、甚至几十倍以上
2、库存量少,一般秒杀活动商品量很少,这就导致了只有极少量用户能成功购买到。
3、业务和流程较为常见,一般都是下订单、扣库存、支付订单。

技术难点

1、若秒杀活动若与其他营销活动同时进行,可能会对其他活动造成冲击,极端情况下可能导致整个服务宕机。
2、页面流量突增,秒杀活动用户访问量会突增。需确保访问量的突增不会对服务器、数据库、Redis 等造成过大的压力。
3、秒杀活动库存量小,瞬时下单量大,易造成超卖现象

架构设计思想

1、限流:由于库存量很少,对应的只有少部分用户才能秒杀成功。所以要限制大部分用户流量,只准少量用户流量进入后端服务器。
2、削峰:秒杀开始瞬间,大量用户进来会有一个瞬间流量峰值。把瞬间峰值变得更平缓是设计好秒杀系统关键因素。一般的采用缓存和 MQ 实现流量的削峰填谷。
3、异步:秒杀可以当做高并发系统处理。即可以从业务上考虑,将同步的业务,设计成异步处理的任务。
4、缓存:秒杀瓶颈主要体现在下单、扣库存的数据操作中。关系型数据库写入和读取效率较低。若将部分操作放到缓存中能极大提高并发效率 (如使用 Redis 操作库存)。
5、扩容:增加服务器数量和数据库、缓存等服务端的数量,物理层面增大处理并发请求的能力。

客户端优化

1、秒杀页面:
如果秒杀页面的资源,如:CSS、JS、图片、商品详情等都经后端,服务肯定承受不住。如果将这个页面进行静态化,秒杀时肯定能起到压力分散的作用。
2、防止提前下单:使用 JS 控制提交订单按钮,如果非秒杀时间或者已秒杀完成,就不能点击该按钮。

服务端优化

1、对查询秒杀商品进行优化
将首次查询到的商品信息进行数据放入缓存,后面再访问时直接返回缓存的信息。
2、对库存的优化
在设置秒杀活动时就将商品库存放于 Redis 中,在下单扣库存时,直接对 Redis 进行操作。
3、后端流量控制优化(参加用户量过大时)
使用消息队列、异步处理等方式解决。即超过系统水位线的请求直接拒绝掉。
4、部署多台服务器,配置负载均衡。
5、部署多台数据库,代码层面开启数据库的读写分离、提高数据库的可用性。
6、优化数据库查询语句,避免技术原因过多占用数据库资源。

核心思想

1、层层过滤,逐渐递减瞬时访问,降低下游的压力,减少最终对数据库的冲击
2、充分利用缓存与消息队列,提高请求处理速度以及削峰填谷的作用
3、增强服务器抗并发能力

  • 3
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值