现场红包雨 - 紧急项目的技术回顾总结

项目背景:带领团队紧急为年会做一个现场抢红包的小程序,以及对应的大屏同步展示,后台管理控制等。工期为十天,现场参与游戏人员预计1000人左右。

从注册小程序,沟通梳理用户需求,到考虑处理一定量的并发,现场处理各种复杂的情况,这是天也算是风驰电掣了。整体描述一下遇到的问题和整理出来的注意事项。

小程序部分

小程序部分核心的问题卡在了三点

  • 一:小程序的申请注册周期
  • 二:配合后端做好并发处理的方案
  • 三:红包雨动画

首先是小程序的申请注册了,这个硬性的时间节点,也是首先要落实下来的。因为过程中还需要协调提供各种资质等等。 这一块属于硬性限制但没什么技术含量的部分,这里不做赘述

配合后端做好并发处理的方案

1000人左右同时抢红包,也算是有一个小的并发的概念的。

关于这一点,我们主要焦点是在两个思路上

  • 接口定时轮训
  • 通过websocket

接口定时轮训,算是最稳定的方式了。只是需要频繁的请求接口,前端也要加上定时器来回跑,比较耗性能。通过websocket连接,从性能上应该 更优一些,但是没有轮训稳定。加上我们需要轮训的部分只是从redis读状态,负荷没那么大,所以选择了定时轮训的方案。

红包雨动画

小程序对与动画的处理,感觉还是差点意思。用的过程中很多问题。

最开始想简单一些通过js创建动画列表,然后将坐标添加到动画对象上。 通过小程序的setData 来触发更新,完成动画。感觉这是比较规范的思路了。 但是想不到小程序 的setData来添加动画,非常卡。只能换个思路。

后来用的小程序的animation,但是通过animation 来处理动画,也面临一个问题。通过 wx:for 循环animation,当第一个动画 完毕去调用更新 list的时候, 正在进行过程中的animation 动画会 脱离setData的控制。通过for 循环 添加的animation,各种奇葩的bug。最后时间比较赶,只能写死了十几个红包循环做动画。

红包中奖规则

这是核心部分。

    用户的需求是:前一亿投放一部分大奖,订单超过一亿之后,会投放另一批大奖。然后还要允许后续追加奖金。
前一亿投放出去的奖金,要在前一亿订单抽奖完成之后,基本上都反方完毕。

这部分我们讨论出了几个方案

  • 一:设定一个奖金池,里面的大奖随机抽中。
  • 二:提前预生成随机队列,用户中奖情况按次数一次从队列中获取。

最后考虑到预先生成队列,对于处理并发有优势,同时可控性也比较高,基本能满足用户需求,所以我们使用了第二种方式。

并发部分

这属于稍微有一点并发的项目,我们采用了全套的阿里云,包括 主从四台服务器,nginx,redis,oss等。但是配置并没有要求很高。

因为频繁访问的数据,都是在redis。抢红包时中奖逻辑我们又处理成静态规则,所以现场并发并没有出现什么问题。

互动大屏部分

通过电脑投屏到会展大屏,显示当前的红包状态和一些中奖特效。

这里的重点有两个:

  • 中奖效果的队列
  • 投屏硬件效果

中奖效果的队列,主要是处理同时中奖人数太多,不能一起出现的问题。

电脑投屏有扩展屏和复制屏,然后可以将复制屏中截取出一部分投放到大屏上。 这是总结出来的最好的投屏方式了。电脑屏幕的分辨率,基本上会被大屏完爆。投上去还是会有失真,但这样效果算是最好的了

随机浏览