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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u013573133/article/details/78309724

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

 

一、问题描述

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

 

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

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

 

二、优化设计方向

1. 开源节流

2. 引入分布式缓存

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

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

5. 业务设计的合理性

    关于开源节流,目的是尽可能多的拦截的请求,减少mysql层的锁冲突。因为一旦mysql锁冲突多了,mysql响应变慢,但是并发量依然很高,几乎所有请求全部timeout,那么真正支付成功的基本没有,那么这个秒杀系统是失败的案例。因此基于以上的想法,我们就需要拦截尽可能多的请求。

    那么如何做到开源节流,需要以下几个方向:

(1) client端,禁止用户出现double click和double payment的情况。限制client在N秒内只能发出一次秒杀请求。

(2) 在后端服务的Controller层,根据请求用户的Account对象的uuid进行计数和排重。保证一个Account对象在N秒内只能发出一次秒杀请求。(这个步骤防止有hacker穿透client层直接http抓包for循环)

(3) 引入页面缓存,同一个Account对象的uuid,限制访问频度,做页面缓存,N秒内的秒杀请求,均返回同一页面。同一个查询,做页面缓存,N秒内到达的请求,均返回同一页面。

 

关于引入分布式缓存,这里通常使用的是主流的redis。在传统的电商系统或是subscription billing&payment系统中,秒杀的情况都是读多写少的情况。场景都是先查询,如果依然有库存,然后发出写请求进行支付操作;如果没有库存或是结果等待查询时间过长,再次刷新查询请求,所以在整个秒杀过程中,大部分情况下写请求占0.001%,读请求占99.999%。因此,在读多写少的情况下,非常适合使用redis。redis单实例最多可以hold住qps 10w的读请求。因此,在秒杀的读请求99.999%全部查redis。如此限流,只有非常少的写请求能够到达Data Center,和非常少的读请求会miss掉穿透到Data Center去,然而,最多的99.999%的读请求被拦住了。


关于引入MQ,作为请求队列。为了增加支付系统的吞吐量,将秒杀支付的过程变成异步过程。可以使用active mq作为请求队列,对于client提交过来的支付请求(Write),做请求队列,只会透过和库存等量的写请求到Data Center层。例如:库存有3000,这里active mq的BET只会透过3000个message去处理。activemq中剩下的message在处理的时候,直接返回“soldout”。如果业务需求中对生成invoice的下单操作和对invoice的payment支付操作可以分离的话,也可以通过active mq将两个操作做成异步。


关于引入悲观锁状态标记,解决分布式下的数据一致性。由于支付过程中,需要RPC访问Payment Gateway Service,无法使用LocalTransaction来保证数据一致性。因此,在最后写请求进行支付的时候,需要在mysql的payment表中设置一个状态为标记payment status,在访问Payment Gateway的过程中将标志位成processing,通过悲观锁将这条记录锁住,直到Payment Gateway的settle成功后,将payment status置成success。在此期间其他的并发的支付请求无法对相关的invoice账单进行支付,保证分布式数据的一致性。


关于业务设计的合理性,对于没有必须要知道库存数量的case,只需要显示是否有库存,所以缓存可以直接存true和false即可。对于12306的火车票的秒杀情况,分时分段售票也是可以均摊流量的方式等等。

 

三、总结





Client:做开源节流

Web server(Controller层):Account uuid做limit,做页面缓存

Back End Service:请求队列控制流量,做数据缓存

Data Center:垂直切分global shard,水平切分分流数据,悲观锁保证分布式数据一致性

Business Model:考虑均摊流量

    假如实际情况是1000w的请求秒杀一个3000库存的商品,Client端和Web Server端可以挡住30%的无效请求。Redis hold住所有的查询请求,Back End Service层把写请求发送到AMQ中,BET在消费AMQ的时候只有前3000条消息是可以支付成功的,后面的消息处理会sold out。

    以上只是一个设计的思路,具体的细节还是需要根据具体的业务场景而定,离开业务的讨论技术细节是不可行的。





没有更多推荐了,返回首页