• 公司概况
  • 产品中心
  • 工程案例
  • 新闻中心
  • 人力资源
  • 产品手册
  • 在线订单
  • 联系我们
  • 您当前的位置:首页 > 工程案例

    高并发的下单、抢票等问题解决方法的原理分析

    时间:2018-11-06 05:49:47  来源:本站  作者:

      抱歉,这是笔者非常菜时一时起意写的文章,能引发思考就好。现在再看这篇文章,只能嫌弃自己当时水了。innodb的行级锁是在并发更新单条记录时,利用这个特性,可以采用CAS的方式,来达到更新单笔记录的目的。当然,实际秒杀场景要复杂的多,数据库是很脆弱的,流量非常大时,数据库是扛不住的。真实场景会从各个方面减少流量(产品层面、应用各层次、限流、消息队列削锋、优先更新缓存再同步入库等),最终达到数据库的只是很少的一部分流量。

      由于下单、抢票等是要写入数据库的,对数据库进行修改,所以采用的写锁,这样,被锁定的数据表就无法被其他地方使用,无论修改还是查询。比如一位用户购买商品时,锁定了商品表,另一位用户在浏览商品,则不能再去访问这张数据表了,不能访问表,意味着这一段时间加载不出商品,而高并发情况下,有很多的人下单。浏览商品,这段很短的锁表时间被放大化,会拖延整个网站的访问速度。

      3、这样就能解决高并发问题的原因是我们相当于把对数据库操作的代码放在锁文件和解锁文件之间了。这样相当于一个标志位。当用户A试图修改数据时,锁定了这个文件。而另一个用户B也试图修改数据库、但是要执行数据库操作前,先得打开这个文件,而文件锁定了,这样用户B打不这个文件,只能阻塞在打开文件的代码处,这样就不能继续执行打开文件后的代码,只能等待打开这个文件。而用户A对数据库操作完后,解锁了这个文件。此时,用户B可以打开这个文件了,则可以继续对数据库进行修改、删除,同时把这个文件锁死,其他需要对数据库进行操作的用户将一直阻塞在打开文件,只能等待文件解锁,才能对这个数据库进行修改、删除了

    来顶一下
    推荐资讯
    相关文章
      无相关信息
    栏目更新
    栏目热门