高并发的下单、抢票等问题解决方法的原理分析
此篇文章为学生时代作品，大佬们看到这里就别往下看了
抱歉，这是笔者非常菜时一时起意写的文章，能引发思考就好。现在再看这篇文章，只能嫌弃自己当时水了。innodb的行级锁是在并发更新单条记录时，利用这个特性，可以采用CAS的方式，来达到更新单笔记录的目的。当然，实际秒杀场景要复杂的多，数据库是很脆弱的，流量非常大时，数据库是扛不住的。真实场景会从各个方面减少流量（产品层面、应用各层次、限流、消息队列削锋、优先更新缓存再同步入库等），最终达到数据库的只是很少的一部分流量。
①为什么不能用数据库自带的表锁功能？
由于下单、抢票等是要写入数据库的，对数据库进行修改，所以采用的写锁，这样，被锁定的数据表就无法被其他地方使用，无论修改还是查询。比如一位用户购买商品时，锁定了商品表，另一位用户在浏览商品，则不能再去访问这张数据表了，不能访问表，意味着这一段时间加载不出商品，而高并发情况下，有很多的人下单。浏览商品，这段很短的锁表时间被放大化，会拖延整个网站的访问速度。
②如何解决这一问题？
1、首先明确我们需要的只是：在一个用户对一张表进行修改、删除等操作时，不让其他用户去对这张表进行修改、删除等操作。
2、我们可以创建一个文件，在使用下单功能等关于数据库修改、删除的操作前，打开这个文件，然后对这个文件进行锁定，在进行完对数据库的操作之后，关闭这个文件，再对这个文件解锁。
3、这样就能解决高并发问题的原因是我们相当于把对数据库操作的代码放在锁文件和解锁文件之间了。这样相当于一个标志位。当用户A试图修改数据时，锁定了这个文件。而另一个用户B也试图修改数据库、但是要执行数据库操作前，先得打开这个文件，而文件锁定了，这样用户B打不这个文件，只能阻塞在打开文件的代码处，这样就不能继续执行打开文件后的代码，只能等待打开这个文件。而用户A对数据库操作完后，解锁了这个文件。此时，用户B可以打开这个文件了，则可以继续对数据库进行修改、删除，同时把这个文件锁死，其他需要对数据库进行操作的用户将一直阻塞在打开文件，只能等待文件解锁，才能对这个数据库进行修改、删除了
4、只是在对数据库进行修改、删除时锁定本地的文件，而不是锁定数据表，这样用户仍然可以对数据库进行查询，添加等不影响用户浏览网页的访问，商户也可以添加新商品，不会拖延网站浏览等访问速度。
