抽奖系统的流量削峰方案

如果观看抽奖或秒杀系统的请求监控曲线,你就会发现这类系统在活动开放的时间段内会出现一个波峰,而在活动未开放时,系统的请求量、机器负载一般都是比较平稳的。为了节省机器资源,我们不可能时时都提供最大化的资源能力来支持短时间的高峰请求。所以需要使用一些技术手段,来削弱瞬时的请求高峰,让系统吞吐量在高峰请求下保持可控。

​​

最近在做一个小型的抽奖系统,用户中奖之后需要调用转账接口进行虚拟金的转账。转账接口有频控的逻辑,因此不能把抽奖瞬间的大量请求都发往转账系统,必须对请求进行削峰。削峰的方式有很多种,下面就来简单地聊一下。

请求排队

削峰最常用的一种方式是请求排队。瞬时的请求量太大,那么就把这些请求先排队存起来,再依据系统所能提供的消费能力按需消费。在量小的时候,抽奖与发货这两个动作可以是同步的(如下左图),这是一种紧耦合系统,SVR B的处理能力必须跟得上SVR A的处理能力。当SVR A 与SVR B 存在处理能力差异时,可以引入消息队列,把对服务的同步调用转化成对队列的异步消费。

​​

可以用来作为队列的工具有很多,典型的如Message Queue消息队列,也可以利用数据库Mysql或是Redis来实现分布式队列,跟进业务场景来自行进行选择。例如,我在实现抽奖系统的时候,使用的是Mysql,原因是SVR A已经把用户的抽奖信息落地到的数据库,那么SVR B就可以利用Mysql作为一个队列,来达到按能力消费的需求。

Mysql

用户中奖的时候,SVR A 会将用户中奖信息写到数据库中。SVR B按照自己的消费能力,从数据库中把数据select出来执行转账的逻辑。数据库表中的每一行记录,都可以看作是一个等待被消费的消息。如何保证消息按序(正序或倒序)消费?可以利用update_time 来标记消息入队时间,设定update_time字段:


 update_time timestamp NOT NULL ON UPDATE CURRENT_TIMESTAMP  DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间'

必须使用一个字段来标记某行记录的消费状态。消费过的消息不必再select出来处理。另外,在有多个消息消费者的时候(比如有多个线程来消费数据库中的这些中奖信息时),需要保证消息不会重复被消费。可以使用二段式提交的方式来保证。以字段present_flag来表示消费状态,present_flag有三个取值:
0:中奖,未转账
1:一阶段提交(即准备转账)
2:二阶段提交(转账完成)

对于SVR B ,需要进行如下的操作:
步骤一:将数据库中present_flag 为0 的记录按序捞取出来,这里可以批量拉取,比如一次拉取100条记录
步骤二:按序处理每笔中奖记录的转账逻辑,调用转账接口之前,将present_flag设置为1,sql中的条件是present_flag为0;
步骤三:执行转账逻辑
步骤四:转账成功,将present_flag设置为2,sql中条件是present_flag为1。

这样即使同一行记录被多个消费者拉取出来,也能保证只有一个能够成功执行步骤三。转账失败(消费失败)
的记录如何处理?可以使用一个定时脚本将present_flag为1的update成present_flag为0,再次进行消费。

通过这种异步消费的方式,来保证中奖记录慢慢被消费完。这种方式在极端的情况下,比如刚刚执行完步骤三
机器就挂掉了,那么可能会出现重复消费的情况。根据业务对重复消费的容忍度来进行选择。

Redis

Redis的list数据结构提供了BLPOP和BRPOP,表示列表的阻塞式弹出。BLPOP的BRPOP的区别仅仅在取元素的位置不同。使用方式为:

BRPOP key timeout
 

当给定的列表内没有任何元素可供弹出的时候,连接将被阻塞,直到等待超时或发现可弹出的元素为止,超时参数 timeout 接受一个以秒为单位的数字作为值。超时参数设为 0 表示阻塞时间可以无限期延长。相同的key可以被多个客户端同时阻塞,不同的客户端会被放进一个队列中,按照【先阻塞先服务】的顺序为key执行BRPOP 命令。利用这个特点,可以来实现一个轻量级的消息队列服务。

消息队列组件

例如kafka、ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ等消息队列,本就是为异步化消息消费、应用解耦、流量消费而设计。业务根据需求加以选型即可。

posted @ 2018-11-11 20:32 melonstreet 阅读(...) 评论(...) 编辑 收藏