抽奖活动的公平性与防刷

抽奖程序的第一条原则：中奖概率只能在服务端算。前端只负责播动画，概率、库存、发奖全部放服务端，这是公平性和防刷的共同前提。 一、概率服务端化 服务端用权重表抽奖：奖品表里每个奖项带权重，程序生成随机数落进对应区间即中奖。扣库存用数据库条件更新保证原子性： UPDATE prize_pool SET remain = remain - 1 WHERE prize_id = 5 AND remain > 0; 扣减失败就发谢谢参与。权重配置放数据库或配置中心，调整概率不用发版，改完即时生效。前端写死"每五次必中一次"之类的逻辑，抓包改个返回值就能绕过，属于原则性错误，审核时一票否决。 二、频率限制 同一用户用 Redis 计数限次： INCR draw:20261008:uid_9527 EXPIRE draw:20261008:uid_9527 86400 超过当日次数直接拒绝。IP 维度再用 Nginx 的 limit_req 挡一层，防脚本批量刷。注册环节加验证码，是成本最低、效果最直接的手段。再配上黑名单：确认过的小号 IP 段直接拉黑，比事后追奖省力。 三、审计日志 每次抽奖都记录：用户 ID、IP、时间、抽中结果、消耗次数。中奖记录单独存表，并与奖品库存对账，发出去的奖和核销掉的奖要能一一对上。活动结束后导出中奖名单留档，有争议时拿流水说话，不靠回忆。日志写进数据库而不是只写文件，文件会丢，库里的记录才能当证据。 四、活动前检查 提前压测接口，峰值按传播人数放大三到五倍估；奖品池数据预热进缓存；中奖和发奖异常配置告警，第一时间通知到人。奖品发完的兜底逻辑提前定好：补货还是发替代品，写进活动规则。活动页面建议放在带防护的机器上，比如高防云服务器 S2 或 S4，把恶意流量挡在门外，真实用户才有机会参与。 抽奖模块代码不多，出问题都在细节：概率算错、库存超发、流水缺失，每一项都会变成纠纷。上线前的自查清单值得认真过一遍。活动规则页面写清概率与上限，既是合规要求，也是减少客诉的第一道防线。