PHP仿微信发红包领红包效果

二、发红包

由于支付成功之后，红包就马上发到聊天界面了，所以在左图“塞钱进红包”时，就把红包信息插入 red_packet 表（支付状态未支付），并分配好金额、计算手气打乱后插入 red_packet_log 表（领取人和领取时间为空），右图“确认支付”成功之后，更新 red_packet 表的支付状态，然后发出红包。

三、领红包（这里只针对群红包进行分析）

领红包的各种前提校验请自己脑补，这里说一个抢群红包的并发问题（群里的几十个人抢几个红包），引入mq来解决。在发红包的时候，先把红包个数依次写入mq，比如发3个红包，就依次写入1、2、3。抢红包的时候从mq取值，取得到数字说明你是第几个抢到红包，对应 red_packet_log 表里的第几个红包，接下来的就是更新 red_packet_log 表的领取人和领取时间，以及余额加钱以及记流水等业务处理了，然后返回领取结果；取不到数字的当然就说明没有抢到红包，直接出“手慢了”的界面。前期有考虑把 red_packet_log 表的主键写入mq，可以省去排序拿第几条log记录，但这样会让“领取消耗时间”这个字段的更新更加麻烦；采用mq存数字，则可以直接比对是否是最后一个红包（取到的数字等与红包个数），然后更新消耗时间。

微信红包的领取结果页（即查看手气页）有很多种：单个和群结果不一样，发红包的人和领红包的人看到的也不一样，单个和群红包过期之后提示不一样等等，这里不一一列举，基本都是根据界面查数据库而已。

四、需求变更，新增第三方支付

说到第三方支付，就要提及同步和异步回调，还有回调时间差。app端在同步回调成功的时候，就会把红包发出去了（app端的支付同步回调是直接调用callback的），如果此时异步回调慢了一两秒，那么用户就会抢到这个支付状态为0的红包。如果说让app端调用长连接接口去查异步回调是否已经成功，再发出红包，则用户体验比较差。