关于高并发支付、秒杀的一些设计思路

于高并发支付、秒杀的一些设计思路

 

一、问题描述

高并发支付和秒杀的场景有很多，Amazon黑色星期五、天猫双11促销、京东618等情况都是如此。假如Amazon某件低价商品只有100个，库存也就是这100份，不会再变了。在00：00秒杀开抢的那一刻，会涌入非常多的流量进程查询（Read）和下单支付(Write)操作。这就是一个非常典型的秒杀支付场景。

 

由于支付业务开发中，和钱相关的业务是非常重要的，不能出现任何差错，所以需要依赖关系型数据库例如mysql的事务和锁的机制来保证数据的一致性。因此，对于秒杀支付的场景中，瞬时流量激增，并且都是读相同的数据，update相同的数据。造成mysql读写冲突，锁严重，各种的锁等待，锁fail等情况。这就是我们在支付秒杀业务中遇到的实际案例。

下文总结一下优化秒杀支付业务的设计思路与方向。

 

二、优化设计方向

1. 开源节流

2. 引入分布式缓存

3. 引入MQ请求队列与异步操作

4. 引入悲观锁状态标记，解决分布式下的数据一致性

5. 业务设计的合理性

    关于开源节流，目的是尽可能多的拦截的请求，减少mysql层的锁冲突。因为一旦m