InfoQ专访丁奇:阿里云即将开源AliSQL,针对秒杀等优化的MySQL分支
电商的秒杀（抢购）场景，其实就是减库存，对数据库而言，就是对一条记录的更新。
因为事务的特点，单条记录的更新必须串行完成，
但秒杀的特点，就是在某个时刻，大量的并发进行减库存，
这就造成了大量的线程因获取不到锁而处在死锁检测状态，
消耗了大量的CPU资源，最终导致系统无法响应，而引起雪崩效应。
AliSQL针对这样的场景，提供了排队和限流的功能，
经过了双11零点时刻高并发请求的考验，保持了系统的稳定性和持续吞吐能力。
电商业务高峰有两个对数据库挑战比较大的场景：
1.超大并发
MySQL能够支持的并发活跃连接数是有上限的，理想情况下是大约（CPU核心数×2）个活跃连接数，
当活跃连接数远超这个值时，性能会急剧下降，导致整个业务不可用。
AliSQL有水位控制，当压力超过数据库的处理能力时，会主动放弃后到的请求，
这样保证数据库还能保持很高的能够正常响应的吞吐量。
2.秒杀场景
在秒杀场景里面有一个减库存的问题。
大量用户同时抢购同一个商品的时候，需要同时更新商品库存，
这时候InnoDB的行锁加上死锁检测机制会导致数据库CPU短时间内被占满，导致整库几乎无法响应。
在AliSQL我们有针专门针对秒杀的方案，保证在大量线程同时减库存时仍能保持很高的TPS。
除了阿里自己的秒杀业务，这个功能同样适用于抢红包这样的业务，已经在2015、2016年春节经过大量的业务验证。

小米网第一版抢购系统：
在PHP服务器上，通过一个文件来表示商品是否售罄，如果文件存在即表示已经售罄。
PHP程序接收用户抢购请求后，查看用户是否预约以及是否抢购过，然后检查售罄标志文件是否存在。
对预约用户，如果未售罄并且用户未抢购成功过，即返回抢购成功的结果，并记录一条日志。
日志通过异步的方式传输到中心控制节点，完成记数等操作。
最后，抢购成功用户的列表异步导入商场系统，抢购成功的用户在接下来的几个小时内下单即可。
这样，流量高峰完全被抢购系统挡住，商城系统不需要面对高流量。
整个系统使用了大约30台服务器，其中包括20台PHP服务器，以及10台Redis服务器。

从上面的阿里和小米的经验可以看出，在大规模并发抢购商品的的时候，
如果直接连MySQL进行UPDATE，数据库会撑不住，
阿里的方法是优化MySQL，小米的方法是用PHP+Redis先处理。

你指的文件锁是把整个mysql/data下的数据库文件锁上？一般没人会这样用吧，这样本业务的安全性当然可以百分之百保障，但是会严重影响其他同在一个文件中数据库中的业务执行效率啊。

我觉得对高并发数据库最大的优化就是能不请求就不请求，尽量减少IO次数，为了保证数据的一致性，最好还要保证请求的串行执行。

数据库始终是我们的瓶颈。减少数据库访问是提高效率的好方法