需求是以抢购的方式向不定量(总量90万,平时访问峰值1万)的用户发放100个兑换码,活动会有预热阶段,也就是实际访问量应该会高于平时峰值数。
要求能够支撑上述数量用户的抢购、发放要求。
首先,类似这种抢购类活动,比如会有较大的访问压力,所以此活动将会以独立项目的方式单独部署,避免对其他系统造成影响。
整个业务共分为三个阶段,1.活动落地页。2.抢购页。3.兑换码发放页。
针对整个业务过程,3个页各有自己的优化思路。
首先,落地页是静态页面,但会有一个动态的活动计时,目的是为了增加用户的紧迫感,这里针对动态计时,采用前端处理的方式,将压力完全转化到用户端。针对静态页做了负载,并上了CDN。
在抢购页,考虑到直接使用按钮抢购会带来较大的并发,所以从业务角度,人为的增加用户的操作步骤来降低整体的并发请求,这里采用的是手机验证码的方式,人的输入速度总是有快有慢,必然会让并发压力降低非常多。
抢购后主要处理发放逻辑,并在发放页展示结果,那么发放逻辑也是重点,由于发放数量固定,所以会提前在redis里生成相对数量的兑换码,并基于redis单线程和出栈的设计来保证发放的有序性和唯一性。但这里的发放是由多步完成,而redis又没有事务的概念,所以采用了lua脚本的方式,借助redis单线程的特性,一次性完成相关事务,并入库。这里的设计从性能角度来看确实有些不够完美,但到了发放阶段,对性能要求已经并没有那么高了,反而业务稳定性和数据一致性变为了重点,所以这里是权衡的结果。
活动较小,但其实中间确实还是有不少要考虑的东西,记录下来作为参考。