秒杀中超卖问题及各层解决方案

本文探讨了秒杀系统的超卖问题及其解决策略,包括应用层的本地存储解决方案,网络层的CDN缓存,负载层的高可用性设计如Nginx和Keepalive,以及数据库层的乐观锁和悲观锁。同时,介绍了高并发场景下的架构设计,如动态页面静态化、Redis缓存、RabbitMQ异步处理、限流策略和数据库的读写分离、分库分表等技术。
摘要由CSDN通过智能技术生成

1.1 秒杀系统架构

秒杀技术特点

读多写少

举例:

淘宝商场在双十一活动时,可能有几千万人在浏览同一个商品,而在这个时间点里读的是特别多,但是真正买到商品的人特别少

高并发

举例:

可能同一时间有很多人都在抢购同一件商品,然后不管抢到抢不到都会发送请求给后端,给后端服务器造成压力,这就是高并发

资源冲突

举例:

比如有1000件商品,然后有多个人对数据库进行写的操作,也就是减1操作,有没有可能最后卖出了1002件商品,这是不可能的

在python2中,使用多线程进行count操作,如
count=1000,
用100个线程每次进行减1操作      count-=1    
然后减1000次,它可能是1或者是2
因为它有些减的操作被覆盖了
1.超卖问题
  • 1000件商品
  • 第一步查询商品数量
  • 查询商品:A 读 商品 1000 B 读 商品 1000
  • 扣减库存:A : 1000-1 =999写入数据库,B:1000-1=999
  • 卖了两件商品,商品数量:999

2.乐观锁和悲观锁如何解决超卖问题的

悲观锁是读取时加锁,然后在写入到数据库之后释放锁
乐观锁是读取时不加锁,写入数据库时加锁
  • 悲观锁解决的原理(商品数量查询那一刻加锁)
    • A读商品数量是1000,如果要是悲观锁,A读完数量后商品就加锁(排它锁)了
    • B过来商品数量,A加的锁还没有释放,所以B要等待
    • 只有当A卖完商品,商品数量减一,把商品数量为 999重新写入到数据库才释放锁
    • B获得商品时商品数据量是999而不是1000
  • 乐观锁解决的原理(扣减库存那一刻加锁)
    • A读商品数量是1000,如果要是乐观锁,B过来还是可以读1000,此时没有加锁
    • A进行商品扣减的时候会校验,现在的商品数量是否和开始数量
  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值