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，异步更新到数据库，有考虑这块的设计，但时间问题当时没有去实现。
最后放个小程序码，有兴趣的可以体验一下。
