微信答题抢红包小程序实现思路
1.背景
18年快年底的时候,有一天突然想要不要做一个抢红包的小程序春节期间玩玩,但是又不能直接跟微信一样直接抢吧,后面想着就引入答题这种模式,答对一次抢一次红包,答对可一直抢到最后,答错则结束抢红包,大概就是这样一个玩法,看着挺简单的一个功能,其实全流程下来要考虑的点也是不少,下面就简单做一个思路的介绍:
2. 资质相关的一些问题
1.申请小程序:
小程序个人、企业都可以申请,但是因为需要包红包涉及到支付功能,必须企业资质,所以找代理注册了一家公司,注册公司全流程也还是挺多事的,这里不细讲,反正有了公司后,又进行了微信公众号认证,然后用企业资质申请小程序,微信支付等。
2.小程序服务类目:
红包类小程序因为涉及到用户资金,按照规范服务类目应该使用社交红包,但是该类目下同样要求《增值电信业务经营许可证》,该证办理也比较麻烦,如果正式商业化建议还是办理,我们暂时使用的其它类目。
小程序社交红包类目
3.核心功能
1.包红包
包红包的时候设置题目、金额、数量,其中题目可自定义或者随机,自定义是用户自己设置题干,选项,答案等,随机题使用的我们的题库,生成红包后可分享小程序。
- 抢红包
用户点开小程序,会随机获取一个题目,自定义题则从用户自定义题库里选,随机题则从系统题库中选,用户答对后则获得一个红包,继续答下一题,答错则结束抢红包。 -
提现
抢到红包后可马上进行提现,提现功能使用的微信支付“企业付款到零钱功能”,该功能开通有一个坑就是T+1结算周期入驻需满90天,且最近30天连续不间断保持交易,对于新开的商户肯定不满足的,所以我们的结算周期用的T+7的,当然结算周期其实是看微信支付商户开通的时候选择的行业来的,不是自己决定的。
企业付款到零钱
4.风险点考虑
做跟钱打交道的功能,就一定要考虑风险,比如是否会被攻击,羊毛党是否能褥羊毛,上线第一天就被攻击了一波,当时有个漏洞差点就被褥了。
- 抢红包金额和数量不能抢到负数
假设群里面一百人抢最后一个红包,那只能让一个人抢到,或者别人恶意攻击时,大并发流量抢红包。
解决方式:数据库在减金额或者数量的时候where 后面加条件,如果写的代码里面先从数据库查出来,发现金额或者数量满足,就直接去减了,并发数高的时候,可能一百个请求去查的时候都是满足的,但是最后数据库去执行的时候只一个满足,没控制好数据库金额和数量就会减到负数。 - 提现的时候不能提现到负数
同样的别人假设恶意攻击,同时一百并发提现,不能让金额提现到负数,防止恶意提现。
解决方案:同样是在数据更新的时候加where条件,不能只在代码里面校验。 - 生成红包金额算法
算法是参考的网上的,实时计算红包金额,没有提前去生成各个红包金额,实时计算规则每次生成红包金额为[0.01,剩余红包金额平均值*2),右边是开区间。
/**
* 获取随机金额,注意剩余金额不能小于0.01*remainNum
* @param remainMoney 剩余金额
* @param remainNum 剩余数量
* @return
*/
public static BigDecimal getRandomMoney(BigDecimal remainMoney, Integer remainNum) {
// remainSize 剩余的红包数量
// remainMoney 剩余的钱
if (remainNum == 1) {
//如果只剩一个,则返回所有金额
return remainMoney;
}
Random r = new Random();
double min = 0.01; //
double max = remainMoney.doubleValue() / remainNum * 2;
double money = r.nextDouble() * max;
money = money <= min ? 0.01: money;
money = Math.floor(money * 100) / 100;
return new BigDecimal(money);
}
5.关于性能
对性能要求高的就是抢红包这块,如果真的是大规模用户用,抢红包这块的设计就很重要,我们有用到redis,但redis只是做了比如题目的缓存,抢红包这块目前还是写db,如果要提升性能的化,抢红包过程可以全部走redis,异步更新到数据库,有考虑这块的设计,但时间问题当时没有去实现。
最后放个小程序码,有兴趣的可以体验一下。
学霸抢包首页小程序码.png