请问抢购的时候为什么选择用PHP文件锁而不是MySQL锁机制,PHP文件锁有什么特殊优点吗?
请问抢购的时候为什么选择用PHP文件锁而不是MySQL锁机制,PHP文件锁有什么特殊优点吗?
你指的文件锁是把整个mysql/data下的数据库文件锁上?一般没人会这样用吧,这样本业务的安全性当然可以百分之百保障,但是会严重影响其他同在一个文件中数据库中的业务执行效率啊。
2 回答3.1k 阅读✓ 已解决
2 回答1.5k 阅读✓ 已解决
2 回答1.2k 阅读✓ 已解决
2 回答1.4k 阅读✓ 已解决
2 回答1.3k 阅读✓ 已解决
1 回答1.4k 阅读✓ 已解决
1 回答988 阅读✓ 已解决
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先处理。