抽奖活动的高可用、高并发优化

这几年工作中做过不少营销活动，这里以抽奖活动为例，讨论一下如何设计出一个高可用、高并发的营销系统。

高可用、高并发架构的核心是分流和限流。系统架构时，应根据每一种营销活动的场景与特性，制定不同的分流、限流方案。

一 业务

在开始进行架构讨论前，我们的简单描述一下业务，以方便我们有针对性的进行讨论。

1.  业务需求

公司希望拉更多的新用户来注册我们的app，所以想通过一个抽奖活动，用一些奖励和刺激的手段来促使用户使用我们的app，并通过奖励手段让用户帮我们一起推广宣传。业务主要诉求如下：

用户需要在app中或者活动页面（H5）中进行某些操作，以获取抽奖机会；例如分享给好友以后奖励一次抽奖机会。

每天每人最多拥有N次抽奖机会。

活动结束后给中奖用户发奖品。

每个人只能中一次奖。

 ……

 

2.  抽奖主流程

这是系统的核心流程，也是后面进行性能优化的核心内容。

 

3.  分析

对活动而言，最重要的是曝光量，只有更多的分享与传播，才能让更多的人参与进来，活动效果才越好，对技术上的要求就是能够提供尽可能好的用户体验。

抽奖活动的页面中，大部分内容都是静态的，只有抽奖按钮需要与服务端交互；对此可以通过客户端、CDN缓存等提升用户体验。

营销活动是拿真金白银来推广，所以需要有效的机制能防止被人恶意攻击，将全部奖品刷走。

如果活动中奖品价值都较高，此种情况下，通常奖品数量有限，中奖概率不高，所以即便是抽奖的并发量较大，实际写DB的压力也并不大，即在扣减奖品库存、向DB中插入中奖记录等环节的写压力并不会大。

如果活动发放类似于优惠券的虚拟奖品，数量可能很大，中奖概率非常高，那么当抽奖并发量大时，写DB的压力会很大。

 

二 核心指标

1.  高并发

营销活动对系统性能的要求，一般来说比常规业务高出很多；如果推广的效果比较好，流量可能会远超初始预期。基于此，系统应该能够支持较高的并发，并且在流量快速上升并超过容量规划时，能够及时、方便扩容。

2.  高可用

核心是提供尽可能好的性能支持，让更多人能够使用我们的产品。具体见高性能优化部分内容

3.  隔离性

营销活动不能影响常规业务；因为营销活动变动频繁，修改时应尽可能的避免影响到其他业务；前一次活动应该能够沉淀出一些内容，降低下一次类似的活动的实现成本。

4.  低耦合

根据上面的需求我们可以看到，营销活动旺旺与主业务有交集。营销活动的特点是变化频繁，定制化需求多，应尽量降低营销活动与常规业务的耦合性。

可以考虑通过旁支流程来解决此问题。例如，用户在app上操作以后奖励抽奖机会这个业务，将用户的行为作为事件，通过MQ消息向外广播，营销活动监听相关的MQ消息，根据MQ消息给用户奖励抽奖机会。

5.  防刷

在营销活动利益的驱动下，常常会有人找系统漏洞，钻系统空子，通过一些手段来刷系统奖品，影响营销效果。一般而言，有以下常规问题需要防范：

防恶意注册用户

防恶意调用接口

防奖品被少部分人获取

防用户误操作

三 架构

高并发的核心思路是逐级分流，逐步分散流量。

高可用的核心思路是通过备份、限流、降级、熔断等手段提升可用性。

1.  整体思路

充分分流，通过缓存、队列、消息等手段将大流量逐步分散。

以空间换时间，通过缓存来提升每个请求的处理速度，提升系统并发量。

异步处理，分析并识别出可以异步处理的逻辑，将他们异步化。

分层逐级拦截非法请求，仅让有效的请求到达底层系统；尽可能让每一次写操作都能成功。

根据每个系统的服务能力，设定流量极限，流量超过极限值后进行限流。

 

2.  分阶段优化模型

为了达到最高的并发性能，需要对整个环节的各个环节进行优化。现实中往往通过如下的倒三角形模型来逐层优化。

注意：这里不过多讲述概念性的内容，而是根据抽奖的需求讲述一些常规的方案；更多内容见博客《高并发技术》

客户端优化方案有：客户端（app、浏览器）缓存。

网络优化方案有：动静分离、静态化

服务端优化包括：缓存（硬盘、堆、分布式）、通信模型优化、异步化技术、线程池、DB存储优化。

响应优化包括：返回结果压缩。

3.