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

个人记录：2018年，工作的第6到7个年头。

重点研究自己不太擅长的技术：分布式、高并发、大数据量、数据库优化、高性能、负载均衡等。

个人看法：

不是很赞同。

只看“最优解”、“最佳实践”，并不是“最佳实践”。看看不太妥的方法，也能促进思考。

前几篇文章中，已经有人有类似看法了，难道这批人年龄较大，一直在用mysql的myisam存储引擎？

之前的文章，已经有“分布式锁”标准解决方案了，不再赘述。

今后，不会再转载类似文章了。

尤其是这篇，标题高大上，在我看来“文不对题”。

准确标题应该是：使用文件锁，解决单机并发问题。

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

原文链接：http://blog.csdn.net/key_next/article/details/51464481

①为什么不能用数据库自带的表锁功能？

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

②如何解决这一问题？

1、首先明确我们需要的只是：在一个用户对一张表进行修改、删除等操作时，不让其他用户去对这张表进行修改、删除等操作。

2、我们可以创建一个文件，在使用下单功能等关于数据库修改、删除的操作前，打开这个文件，然后对这个文件进行锁定，在进行完对数据库的操作之后，关闭这个文件，再对这个文件解锁。

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

4、只是在对数据库进行修改、删除时锁定本地的文件，而不是锁定数据表，这样用户仍然可以对数据库进行查询，添加等不影响用户浏览网页的访问，商户也可以添加新商品，不会拖延网站浏览等访问速度。