为了账号安全,请及时绑定邮箱和手机立即绑定
  • 该节视频涉及到sql优化

    查看全部
  • 使用存储过程,对 mysql事务行级锁的效率进行优化,一次编译,多次使用,减少编译时间<br/>
    查看全部
  • 执行存储过程

    查看全部
  • 20、21、22: insert_count 小于0 ,这只能是出错,故以 R_RESULT = -2 代表出错,作为返回值返回;

    23~25:以上已排除 insert_count 及插入返回结果 小于、等于0的,剩下的只能是大于零,由于每次只有一条数据进来,故只能返回 1 ;执行update 减库存操作,对number-1

    26~ 29 :并根据活动或秒杀商品的id对活动的开始、结束时间与活动时间周期校验是否处在同一区域内,并验证活动商品量是否仍 大于零

    30:使用 select row-count() into insert_count 来获取减库存操作的有效返回值

    31~40 : 根据 减库存的返回值判断是否执行减库存成功,若 insert_count <=0;则说明失败或出错,并返回 0 或 -2 ;余下的结果只能是成功,设置返回值为 1 ;


    查看全部
  • 2:用到 mysql 的 DELIMITER ,使用 $$ 作为换行符,类似于;

    7: 定义存储过程的名字: 创建存储过程 名字.名字

    8、9: 存储过程中输入、输出的参数

    10: BEGIN  表示 开始编写存储过程的具体内容

    11:判断一个变量,该变量名为 insert_count ,后面是具体类型及默认值

    12:开启事务  transaction

    13:插入购买记录 到 用户记录表

    14、15:表示具体要插入哪些数据到哪些表参数上

    16:查询 上一次 insert_count 返回的有效值

    17、18、19 : 当上一次执行的有效值 = 0,说明插入操作失败,回滚,并 设置     R_RESULT 代表重复秒杀


    查看全部
  • 业务逻辑层面的优化,将用户的每次购买记录到 insert  到数据库的操作提前到减库存之前;

    并获得返回值 insertCount ,其代表当前用户执行了一次秒杀操作;

    当用户在前端页面重复点击多次购买时,该 insertCount> 0时则说明当前用户已购买,不再进入到下一步的减库存操作;

    从而避免了行级锁频繁无功用访问执行时带来的效率问题;

    最后,如果insertCount <=0时,允许进入到减库存的操作。


    查看全部
  • 优化:

    前端: 动静态数据做分离,减少请求与响应时间;按钮防重复,防止用户发送无效的重复请求,因为秒杀活动一般都会有购买数量的限制,敲的次数再多,最后还是要查看是否已购。影响了效率,可有前端代为处理并优化

    后端:使用CDN换存重要的静态资源等;在后端对活动结束时间、商品选购时间、业务的相关逻辑要求都放在后端代码中,并调用缓存来进行暂存,已减少对DB的直接操作,提高效率

    查看全部
  • 第一个用户执行一次商品购买时,对DB的update减库存操作不是执行完就结束,后续还涉及到GC内存满了,等待自动回收过程中的网络响应的延迟问题;除此之外,用户的每一次购买操作都是一个具体的事务,其中还涉及到了用户个人的购买明细,可理解为淘宝的已购买这一项,而这又是一个insert 的操作,执行完后又或许可能再一次出现GC进行内存的清理而导致延迟,直到反应过来后,继续执行后续的事务提交commit或者失败后的回滚rollback

    而这时另一个用户的update 操作已经开始很久了超过了 4W分之一秒的理想时间,所以,实际秒杀项目中,需要对每一个用户的update时间,即行级锁的时间进行优化,因为,下一个用户还在等待,他后面或许还有一个它也在等待....哈士奇瞪着眼等着呢

    查看全部
  • 压力测试下,一条update 可以 达到 4W 的 QPS ,等同于一件商品能在一秒内被销售掉 4W 件,这应该是理想值吧!

    那么,对于实际执行中的低效是什么原因?这才是并发中要优化的重点吧!

    查看全部
  • 使用redis/NoSQL的数据验真,将逻辑操作解析等校验后调用MQ进行解耦,发送消息队列,或调用MQ的异步操作提高效率异步处理事务;最后根据队列执行结果对MySQL进行操作,这一步需要根据消费消息的结果来操作,即落地实现

    查看全部
  • 秒杀优化原因:

    (1)无法使用CDN缓存,其只针对核心数据做缓存

    (2)在后端库存操作中,不能在缓存中减库存,极短时间内不同用户的缓存数据不同,变化大,容易造成超量

    (3)某一个热点商品被同一时间由多人竞争时会产生大量的update操作,DB效率及错误率需要优化

    查看全部
  • 一致性维护:

    缓存半小时,半小时之后,这个redis的秒杀对象就会超时,超时之后 ,重新访问mysql服务器获取数据,或者是当我们的mysql更新时 我主动的更新一下redis缓存,这样也非常方便      暴露秒杀地址

    查看全部
  • 212331

    查看全部
    0 采集 收起 来源:系统部署架构

    2019-07-03

  • 12312312

    查看全部
  • 3213123

    查看全部

举报

0/150
提交
取消
课程须知
《Java高并发秒杀API》是系列课程,共四门课,分别为业务分析和DAO层,Service层,Web层和高并发优化。本门课程是第二门课程,学习前需要了解如下知识: 1、精通JavaWeb基础 2、熟悉SpringMVC、Spring和MyBatis框架 3、了解事务和存储过程的概念
老师告诉你能学到什么?
1、掌握秒杀业务 2、能够进行SpringMVC+Spring+MyBatis的整合开发 3、能够对秒杀业务的瓶颈有所了解 4、能够实现对秒杀业务的优化

微信扫码,参与3人拼团

意见反馈 帮助中心 APP下载
官方微信
友情提示:

您好,此课程属于迁移课程,您已购买该课程,无需重复购买,感谢您对慕课网的支持!