记录一次营销活动的实现

需求是以抢购的方式向不定量（总量90万，平时访问峰值1万）的用户发放100个兑换码，活动会有预热阶段，也就是实际访问量应该会高于平时峰值数。

要求能够支撑上述数量用户的抢购、发放要求。

首先，类似这种抢购类活动，比如会有较大的访问压力，所以此活动将会以独立项目的方式单独部署，避免对其他系统造成影响。

整个业务共分为三个阶段，1.活动落地页。2.抢购页。3.兑换码发放页。

针对整个业务过程，3个页各有自己的优化思路。

首先，落地页是静态页面，但会有一个动态的活动计时，目的是为了增加用户的紧迫感，这里针对动态计时，采用前端处理的方式，将压力完全转化到用户端。针对静态页做了负载，并上了CDN。

在抢购页，考虑到直接使用按钮抢购会带来较大的并发，所以从业务角度，人为的增加用户的操作步骤来降低整体的并发请求，这里采用的是手机验证码的方式，人的输入速度总是有快有慢，必然会让并发压力降低非常多。

抢购后主要处理发放逻辑，并在发放页展示结果，那么发放逻辑也是重点，由于发放数量固定，所以会提前在redis里生成相对数量的兑换码，并基于redis单线程和出栈的设计来保证发放的有序性和唯一性。但这里的发放是由多步完成，而redis又没有事务的概念，所以采用了lua脚本的方式，借助redis单线程的特性，一次性完成相关事务，并入库。这里的设计从性能角度来看确实有些不够完美，但到了发放阶段，对性能要求已经并没有那么高了，反而业务稳定性和数据一致性变为了重点，所以这里是权衡的结果。

活动较小，但其实中间确实还是有不少要考虑的东西，记录下来作为参考。