一 需求描述
实现一个大转盘活动,用户有三次抽奖机会,每次抽奖后给用户返回中奖结果。
中奖概率和奖品在活动前由产品经理给出
一等奖——中奖概率为 1 %,1000 元红包
二等奖——中奖概率为 5 %,100 元红包
三等奖——中奖概率为 10 %,10 元红包
其余为没有中奖
用户通过具体页面可以看到中奖纪录。
二 需求分析
我们发现中奖概率的格式是有问题的,只有中奖概率和奖品,没有奖品数量。没有奖品数量就是对预算没有控制,如果中奖数量超过了预算就会造成损失,所以在需求中要补充奖品数量和活动总预算。
直接实现该需求是比较简单的——对用户的抽奖次数做校验,然后在每次抽奖的时候利用随机数查看用户是否在中奖区间来确定抽奖结果。
但是,作为架构师,要对需求有预判。对于产品的日常运营来说,活动是常规需求,每个月都有形形色色的活动。例如,大转盘抽奖、九宫格抽奖、开箱子抽奖等。这些抽奖活动有不同的前端表现、中奖概率和获取抽奖资格的途径,但底层抽奖逻辑是共性的,我们可以把共性抽象出来,把抽奖部分做成通用的系统,供上层逻辑调用。如果能实现该系统,那么有很多好处。
提升效率:抽奖部分只需修改配置文件即可实现,实现需求时只需要重点关注表现层即可。
提升稳定性:核心抽奖逻辑固定,经过严格测试和多个项目验证,每次活动都是复用代码,并不修改代码,减少了由于程序问题导致发送奖品出错而造成的经济损失。
三 实现方案
1 实现功能分析
1)外部交互
-
增加用户抽奖次数的功能