上海某文化传媒公司游戏活动小程序开发

这个项目是给上海一家文化传媒公司做的活动小程序，配合他们线下展会做互动抽奖。用户进场扫个码，做几个小任务攒积分，攒够了就去抽奖，中奖了现场兑。听起来就是几个页面加个转盘的事，我们一开始也这么以为，结果上线第一天就被教育了：活动小程序真正的坎从来不在功能，在开奖那几分钟的并发。它的流量是脉冲式的，平时静悄悄，活动一开闸全冲进来。

抽奖逻辑我们全部放在后端，前端只负责展示和发请求。库存用 Redis 扣减，目的就一个，别超发。奖品数量是有限的，超发意味着要么自己贴钱补，要么现场客户闹，哪头都受不了。所以库存扣减这条链路，我们从一开始就当命门对待，所有奖品数量、已抽数量、剩余数量全部以 Redis 为准，数据库只做最终落账，两边还要能对上。

结果第一次上线还是出事了。当时图省事，用了先读后写那套非原子操作：先查一下库存够不够，再扣减，两步之间没有加锁。平时压测看不出问题，活动一推出去，流量上来之后，同一个奖品被同时抽出去好几份。客户当场打电话过来，语气已经不对了。后来我把这段改成了 Lua 脚本，把判断和扣减压进 Redis 内部一次跑完，原子性有了保证，才算真正稳下来。这个跟头栽得值，让我彻底记住了：并发场景下，读改写必须原子。

除了并发，防刷也得提前想。活动一上线，就有人拿脚本反复刷任务，想白嫖抽奖次数。我们加了频率限制和幂等校验，同一个用户同一个任务只记一次积分，接口调用频率也做了上限。这些细节平时看不到，一上线就全冒出来，晚一步就是奖品全被薅走。做活动之前，一定要先假设有人会刷。

审核那关也折腾得不轻。微信对抽奖、诱导分享这类玩法管得很严，我们有一版文案里写着“分享给好友获得抽奖次数”，直接被驳回。后来把规则写清楚，去掉诱导性措辞，又单独补了一个活动规则页，把奖品数量、中奖概率、领取方式、有效期全列出来，才终于过审。审核不是跟你讲道理，是看条款，条款没覆盖到的地方，它就用驳回来提醒你。

这件事给我的教训很直接：活动小程序，规则页一定要有，别嫌麻烦。我们后来把规则页当成模板固化下来，每个活动都配一份，写清楚奖品、概率、领取、有效期，既是为了过审，也是给客户一个交代，减少现场扯皮。规则写得越细，后面客服的活儿越少，用户也不容易起疑心。

上线那天的监控我也盯得紧。活动小程序不像普通工具，平时可能一天没几个请求，活动开始那几分钟直接冲到峰值。我们把关键接口的日志和告警提前配好，超发、接口报错、库存告急第一时间能收到消息，不然真出了问题等客户反馈就晚了。当天我盯着告警群看了一下午，直到峰值过去才松口气。

现场兑奖这块我们也没放过。中奖之后生成了一个核销码，现场工作人员扫一下就能核销，防止有人截图冒领。核销记录实时同步，后台能看到哪个奖被领了、哪个没领。别小看这一步，线下几百人排队兑奖，没有核销码全靠人工登记，那才叫灾难。

这类项目活得短、但要求高，一天的高并发就能把你所有的设计拉出来遛一遍。把关键路径想清楚，比什么都强。现在再有人找我做活动类小程序，我第一句话永远是：先告诉我峰值大概多少，库存怎么扣，规则页写没写。