抽奖型电商活动后台技术实践

背景

在某互联网金融平台的会员体系建设中，用户积分是很重要的一环。

用户可以在交易、登录、签到和兑换过程中，按照后台设置的规则获得积分。这些积分又可以参与到各种活动，其中抢购类型的活动，由于其参与门槛低，结果不确定性高，深受用户的喜爱。

活动形式

交互流程

CurrentReq

当前活动收到的有效抽奖活动序列号，每收到一个抽奖请求原子自增。

WinNumber

为保证如10,000次抽奖一定能抽走10个奖品的需求（每次概率计算不能保证一定抽走10个奖品），后台为每次活动设置的中奖号码位置，保证抽到10,000次的时候，10个奖品已经抽完。

{ProductId}_{UserId}

用户在该活动下已经参与的抽奖次数，为保证公平起见，单个用户在单个活动下的抽奖次数受限。

运维保障措施

Nginx限流

在带宽耗光，连接池打满，CPU冲高的情况下，对请求来源IP级别限流。

会误伤某几个IP下的一批正常用户，但是保证了其他IP用户的服务可用性。

抽奖活动专用泳道

在七层负载上，根据抽奖请求特定的URL形式，将服务指定分发到某一组服务器上。剩余的服务器不处理抽奖请求，保证其他业务的正常运行。

活动期间临时服务器扩容

活动量太大，服务器还是的扩容。前提是服务需要做到无状态，可以使用集中式的Session，数据库存储上下文信息。

数据库垂直拆分

将抽奖相关的DB从核心库拆分到独立实例中，避免因为抽奖耗光数据库资源，而影响其他金融交易活动。

静态资源处理

JavaScript/CSS/JPEG/HTML等静态资源，分发到CDN上去，请求消耗的带宽落到CDN上。

启用终端缓存静态资源, last-modified-at/expired-at等HTTP原始信息定义。

存在的问题及改进方案

自动脚本刷单用户限流

在自增用户单词活动抽奖次数的同时，记录服务器端收到用户下单请求的时间。
后续用户发送抽奖请求时，根据最近几次抽奖请求的时间间隔，判断是否脚本刷单。

抽奖请求序列REQ持久化

如果Redis 在活动期间宕机，其中关键的CurrentReq会丢失，恢复的时候从数据库中记录的抽奖请求中恢复。

支付能力检查通过后支付又失败的问题

用户的支付能力一直在变，可以在同步请求中完成用户支付扣减积分后，才去自增CurrentReq以及创建抽奖订单。

为保证响应速度，要求支付服务做得