江苏省城乡和住房建设厅网站,网站为什么做等保,公司官网域名怎么注册,wordpress cdn图片加速1.秒杀系统的特点
瞬时高并发
2.预防措施
2.1.流量限制
对于一个相同的用户#xff0c;限制请求的频次对于一个相同的IP#xff0c;限制请求的频次验证码#xff0c;减缓用户请求的次数活动开启之前#xff0c;按钮先置灰#xff0c;防止无效的请求流入系统#xff0…1.秒杀系统的特点
瞬时高并发
2.预防措施
2.1.流量限制
对于一个相同的用户限制请求的频次对于一个相同的IP限制请求的频次验证码减缓用户请求的次数活动开启之前按钮先置灰防止无效的请求流入系统给系统造成冲击
2.2.页面静态化活动开始前
分析
活动页面是用户流量的第一入口所以是并发量最大的地方。如果这些流量都能直接访问服务端恐怕服务端会因为承受不住这么大的压力而直接挂掉。活动页面绝大多数内容是固定的比如商品名称、商品描述、图片等。为了减少不必要的服务端请求通常情况下会对活动页面做静态化处理。用户浏览商品等常规操作并不会请求到服务端。只有到了秒杀时间点并且用户主动点了秒杀按钮才允许访问服务端。 2.3.CDN内容分发网络
用户分布在全国各地有些人在北京有些人在成都有些人在深圳地域相差很远网速各不相同。
如何才能让用户最快访问到活动页面呢答使用户就近获取所需内容降低网络拥塞提高用户访问响应速度和命中率。 3.扣减库存方案选型
下单、支付、减库存
3.1.下单减库存
即当买家下单后在商品的总库存中减去买家购买数量。
下单减库存是最简单的减库存方式也是控制最精确的一种下单时直接通过数据库的事务机制控制商品库存这样一定不会出现超卖的情况。但是你要知道有些人下完单可能并不会付款。
弊端如果有竞争对手通过恶意下单的方式将该卖家的商品全部下单让这款商品的库存减为零那么这款商品就不能正常售卖了。要知道这些恶意下单的人是不会真正付款的这正是“下单减库存”方式的不足之处。
3.2.付款减库存
即买家下单后并不立即减库存而是等到有用户付款后才真正减库存否则库存一直保留给其他买家。
“付款减库存”又会导致另外一个问题库存超卖。
弊端假如有 100 件商品就可能出现 300 人下单成功的情况因为下单时不会减库存所以也就可能出现下单成功数远远超过真正库存数的情况这尤其会发生在做活动的热门商品上。这样一来就会导致很多买家下单成功但是付不了款买家的购物体验自然比较差
3.3.预扣库存
买家下单后库存为其保留一定的时间如 10 分钟超过这个时间库存将会自动释放释放后其他买家就可以继续购买。
Q这种方案确实可以在一定程度上缓解上面的问题。但是否就彻底解决了呢
A其实没有针对恶意下单这种情况虽然把有效的付款时间设置为 10 分钟但是恶意买家完全可以在 10 分钟后再次下单或者采用一次下单很多件的方式把库存减完。针对这种情况解决办法还是要结合安全和反作弊的措施来制止。
4.方案详解
MYSQL
单个 MySQL 的每秒写入在 4000 QPS 左右超过这个数字MySQL 的 I/O 时延会剧量增长。MySQL 单表记录到达了千万级别查询效率会大大降低如果过亿的话数据查询会成为一个问题。
Redis
Redis 单分片的写入瓶颈在 2w 左右读瓶颈在 10w 左右
4.1.预扣库存
4.1.1.分布式事务扣库存支付 如何保证分布式事务扣库存、支付rocketmq事务消息
4.1.2.热key库存key
库存这个key的访问是非常大的是一个热key由于Redis单机性能10w因此可能会被拖垮
方案1 Redis分片
将库存key分成多个key打散存在不同的分片上比如xxx_stock_key1、xxx_stock_key2、... 扣减库存的过程
先生成对应分片总数的随机不重复数组如第一次是[1,2,3]第二次可能是[3,1,2]每次扣减子库存的请求就会分布到不同的 Redis 分片上缓轻 Redis 单分片压力的同时也能支持更高 QPS 的扣减请求这种思路的一个问题是当库存接近耗尽的情况下很多分片子库存的轮询将变得毫无意义 因此可以在每次请求的时候将子库存的剩余量记录下来当某一个券模板的子库存耗尽后随机不重复的轮询操作直接跳过这个子库存分片这样能够优化系统在库存即将耗尽情况下的响应速度。
方案2本地缓存
本地缓存保存Redis中的库存数据。当秒杀时先查询本地缓存如果数据秒杀没了就不会再请求到Redis了
分析这里存在一个问题引入了本地缓存那么本地缓存和Redis缓存存在数据一致性问题怎么解决呢
答定时器查询完成单量的库存更新到Redis和本地缓存中矫正
