关于年会摇奖背后的故事

腾飞 2017, 又一年年会，又开发一套抽奖系统，这次的抽奖系统与往常的有些不一样，并不是签完到，系统自己进行抽奖。而是增加了许多的互动环节，同时也有一些新技术的尝试。

通过这个年会摇奖项目我发现，我们有一个很棒的团队。

过程中的故事

这个年会抽奖项目由三种后端语言实现，Lua做主要流程的一个尝试，Golang主要用大屏幕、消费队列，php主要做后台，后台功能也是相当强大的。若不是后台功能强大咱们年会可能就出大问题了，相信参考过年会摇奖活动的同事们也有所察觉。

出问题是因为前一天晚上我修改一个微信警告通知的问题而把代码覆盖掉了，覆盖的同时也把value = 1加上去了。

有人会问 value = 1 是什么鬼？

这个可是摇红包能收到的实际金额啊σ(^_^;) 然后自然而然的 大家只收到了1元... 好尴尬啊...

现场调试大屏幕是相当痛苦的

现场的大屏幕的分辨率、比例都是可调的动态调整的。

这就尴尬了，之前按比例也好，按分辨率也好，大部分页页都得重新修改...

真是辛苦咱们权哥了，现场修改了好几个版本。

每次按那个大屏幕工作人员的修改好的值调整好页面后，他一拖...又变了，我们又得重新调页面...

好蛋疼啊...

一些坑及收获

整个过程还是很刺激的，现场总会遇到各种各样的情况，对应变能力要求还是比较高的。

咱们团队配合的相当默契，无论是咱们几个负责这个项目的人员还是咱们组其他成员们，都相当给力啊，执行效率相当高比我想像中的好多了，只要分配下去的任务能立马完成并且完成效果还相当不错，确实特别棒。

签到

签到

签到我们测过无数次了，理论上是不会出问题的，实际也没也问题，逻辑也算比较简单。当看到大屏幕上正常显示祝福语了，我也就是松了口气。

签到逄是顺利过关了。

小宜助手

这个是年会前一天加上去的，当时想的是为了解决有人没有与微信公从号交流而无法正常发送卡券的问题，所以我当时就想要不加个聊天功能吧。

正好以前有接过一个机器人聊天功能，简单配制后就在回复消息里面加入了机器人聊天。

最终我们发现这是一个意外的收获，当天小宜助手也小小的火了一把。与小宜助手交流的人还是非常多的，从数据上看，平均每个人都与小宜助手进行5次以上的对话。最终看这个数据的时候比我预想在的要好太多了。

当然有一部份原因是因为咱们加入了人工回复，哈哈整个过程还是相当有意思的。被调戏过的人肯定有些人一脸懵逼。

看着同事们调戏小宜助手发在朋友圈的截图，还是挺有意思的。

当然也有意外发生，有同事发现回复某些关键字的时候会有一些不良的信息回复，这个是我当时没有考虑的。

收到同事们反馈的消息后，我赶紧加入的关键字过滤，让还没有反映过来的同事，不知道发生了什么。

在年会结束后一天，我们准备停止所有年会服务，然后在微信后台发布一一条消息。意想不到的是，还有居然还有一些的回复消息，看着那些回复的消息我们都挺感动的，随手做的一个功能居然也能给大家留下印象。

摇奖

心脏不好的，还是悠着点

福袋雨

这个也经过了多轮测试，应该问题不大，但实际600人同事摇我还是没有太大的把握，当第一个弹幕出来的时候，我就松了口气...弹幕出来了应该是走通了，我又看了看日志，正常。呼〜〜 这个环节应该差不多了。除去发卡券、模版消息需要时间外应该都没问题，有两个发失败的后台操作重新补发了。

红包雨

其实红包雨原计划是只有一次的，当时现场发了两次。为什么呢？上面也说了...

当时第一轮红包雨是3000元，开始摇了，弹幕已经出来了。可是...

可是我感觉好像有点不对劲，哪里不对劲？说不上来。

于是我上服务器打开代码查看了一下... 卧槽 value = 1，我赶紧问我们组中的同事，让截图给我看。当然如我所想的那样，每个中奖人收到的都是1元。

我赶紧和同事说了这个问题，然后提议补发一次，因为这时正在发200个红包，也就是实际金额200元，若200个全部发完，那只会扣除账户200元。那么账户里还有2800元。都是同事肯定不能就这么糊弄。

于是我们找京京姐(年会负责人)提议再摇一轮红包雨。此时下一个节目已经开始了，我们只有5分钟不到的时间了...得赶紧决定。

经过短暂的沟通，我们决定在下一轮"福袋雨" 结束之后马上进行"红包雨"，但这有风险，微信会有限制，每个人每分钟只能摇25次，若超过25次将会被锁定。两轮奖是连续摇，肯定会出现大量同事微信锁定无法摇的情况，那就有可能会出现奖发不完的情况。

确认再加一轮，与主持人沟通后，咱们就开始工作了，同事在后台增加、配新一轮摇红包。我上服务器，删除value = 1, 重启服务...紧张等待中...

(真庆幸主持人是咱们键哥，配合的相当好。)

第二轮"红包雨"2000元 紧张的进行中... 我们紧盯屏幕和日志。若一旦数字没有继续减少的话，立马关闭抽奖。不过结果还是好的，没有出现奖没发完的情况。

这个时候真庆兴咱们这个做得实在是太棒了，几乎都是可配制化。

大奖

大奖这个也出一些状况。(唉...)

三等奖主持人说的是120个，咱们后台配的是200个....

卧槽...

咱们德龙大哥，听到后立马呼叫京京姐，此时...京京姐并没有带耳麦... 另一同事赶紧找到她并确认，确实是120个。

此时只有不到一分钟的时间了...

德龙听到确认后立马修改参数，重新生成奖品。这速度卧槽...

流程正常进行中...

因为特、一、二、三等奖是同时抽的，因为大奖的抽奖机制问题，所以时间会比较长，并不像抽福袋、红包那样几秒钟奖就已经摇完，大屏幕只是一个效果而已。此时大奖已经进行了一半多了，看着大大屏幕特等奖还没出来，吴哥问我怎么还没出来？我说:"不要急, 先等等看"。德龙上服务器进Redis查了一下数量:"还有14个"，"还有12个"。呼〜特等奖出来了......

太棒了，顿时就兴奋了。剩下的应该就几个二等奖和三等奖了。

我们自己也赶紧摇...

我们开发小组3､4个人一个奖也没中... 这运气... 唉 开生没有中奖的命啊...

当大屏幕显示:"所有奖品已完"的字样时。我们都松了口气，拍了张合影。

// 此处应该有合影

技术/业务 背后

当时接这个活的时候，我就想着尝试尝试其他技术，正好年后咱们想用ngx_lua 和go 来写一些东西，那么这就有机会了，年会是一个很好的实践机会，拿新技术来做。

做到最后，我们发现技术文档已经可以打印出30页纸了。api提供有微信，小程序，后台、大屏幕和所有页面。

那么我选的是ngx_lua来做主要业务流程，php做后台，Go干点啥呢？WebSocket吧(后来go不单单只做了 WebSocket)。

咱们早早的就写完了所有流程，然后在服务器上调试，总是不太稳定，当时也不知道啥原因。

后来有一天正式演示的时候出问题了，一直访问不了，用wifi、4G都试过了，然后过了一会又好了。啥原因？不知道，不知道从哪找问题，我一直怀疑是咱们服务器网络有问题，可又拿不出证据证明是咱们服务器网络的问题，因为它总是偶尔出来不稳定。

因为无法确定是服务器网络问题，所以我只能从程序下手，把可能出问题的环节都做标记，并且拆分开。可似乎好像没啥效果，服务器偶尔还是接受不到请求。

找了几次运维、安全，都没查到结果。

无奈，我提议把项迁出去，迁移至阿里云，排除一下问题，到底是不是咱们服务器网络的问题。只是个提议，还没实施，我只是用我自己的服务器暂做一个迁移的尝试。过程大概用了2､3小时吧，踩了几个坑。

又用了几天调整程序，此是离年会开始还有2天...

我又去找运维确认情况，加个监控，最终在慷师傅那得知。确实是咱们现在服务不太稳定，因为咱们总部新增加了一个白名单的ip段，可能影响部份服务，刚刚好咱们其他服务都没问题，就咱们这个服务有问题。

这是巧合...这是巧合...这是巧合...

最终我们还是自费购买了阿里的一台服务器，我预计的一台服务器足够，按量计费。

这次花了一小时迁移完，因为是新服务器，所有的环境、扩展都需要自己弄，所以比较费时间。当然最后还有一个libxml2的坑，这个坑了我5个小时，在公司5个小时还没搞定，到家5分钟解决... 回家的路上我不害想，实在不行，就再弄复杂些吧，通过另一台机器来跑专门的服务。

这也是巧合...

年会结束后一天我们把服务器释放了，把所有数据取下来进行分析。下图是阿里的监控...

此处理应有监控图表

还有一些其他的图表，我就不一一贴了，从图上很明显能看出，峰值都在4次抽奖上面。其他时间表理的比较平稳，没有太多的波动。

签到

签到与往常一样，通过微信摇一摇进行签到并且绑定用户的微信号并且抽奖也是与签到也息息相关。这次的签到也与以往略有不同，增加了名次、抽签...

// 此处应有图

摇奖

技术这边前段时间我写过一篇《处理微信的并发推送并保证数据的准确性》 里面讲了一下微信的并发推送及处理方案，当然最终由于种种原因我们为了保证数据的准确性做了一个大的调整，当然结构还是不变。

现场服务器压力还是相当大的，最高的时候1分钟，一共接收到了近6000个摇一摇请求，平均每秒100左右的并发，高的并发在开始摇奖瞬间，200多个并发。

并且微信推送每个人同时并不只推送一条记录，可能会有多条。所以并发锁是非常非常重要的。

我们购买的是阿里的4核，8G内存 公网带宽上限100MB，的服务，按我之前所想的，4核理论上应变是够用的，内存也够，问题在带宽这。当时我应该选用独立带宽，这样能更少的战胜公网带宽。另外就是http及https的选择，我所使用的是个人的免费https，因为小程序必须使用https，然而https却比http慢了差不多10倍，从我测试的结果来看是如此。

qps处理http能达到近2000,而https只有200左右。可能是验证https机制的问题，这个还有待研究。

还是说一说红包、福袋及大奖的实现吧

通过后台配制一个抽奖项目，抽奖一共有三种类型: 福袋、红包、大奖，每种类型的处理方式都是不一样的。

每一项甚至都会有一个分值，这个分值决定着你下一轮能不能中奖，当然对大奖并无影响。这个算法由吴哥提供。

福袋

先是通过后台根据规则生成一批数存入队列，等待被消费。队列里有6,7种奖品一共200个，随机存放。当一个用摇进来并验证难过的话会从这个队列弹出一条记录，这个记录就是你的中奖信息。然后经过一些的或者某些加工后存入新队列等待被消费。

Golang启动了一个服务，就是启到消费这个队列的作用。每弹出一个消息后进行验王言目，然后回调上层所开放给本机的api，进行奖券、红包的发送。若发送失败会进入失败队列，后台可以操作重新发送。

为什么不用go直接发送？而是调用上层进行以送？

答: 因为之前因为服务器问题做的调整啊，本来这个队列是不存在的，不是因为无法确定问题所在嘛，只能先拆分服务先试试看喽。

红包

红包，涉及到钱的东西，流程都会变得比较复杂，需要各种证书，并且发送也比较慢。因为必须保证数据的正确及安全性。

流程和福袋一样，只不过是类型不太一样，发送的方式也不一样。出的问题上面也说过啦，木有什么好讲的了...

大奖

大奖包括特、一、二、三等然，这一轮跟前面不太一样，并不是来一个队列就出一个，而是有一定概率的。

大概就是每摇五次能中一个，这还得看运气，若前面有4个人摇了没中，那刚刚好你是第五个，那么恭喜你，中大奖了。这是为了增加互动性而做的调整。

前面红包、大奖都是先到先得，200个几秒钟就完了，屏幕上显示的只是故意做的延迟效果而已，要不然满屏都是弹幕，并且还特别烧CPU，浏览器一会就跑满了。相信中得红包或福袋的人已感到了，点进去显示已中奖，实际微信还没有收到钱或卡卡券。那是因为后端正在努力往微信发送消息，通过中奖，每秒大概能发5-10个左右，所以公众号发奖有些慢。原因前面已经说过，为了保证准确性这也没办法。

大屏幕

大屏幕主要收权哥写，后续我增加了弹幕功能。大屏幕经过了多次大改，多次调整，红包。福袋都由websocket进行控制，后台(php)调用ngx_lua进行验证并处理，完成后连接Go启动的webSocket服务，并向服务推送数据，服务接到的消息后验证是本机推送的消息后把消息推送至大屏幕。也就是说咱们可以后台操控大屏幕显示什么...

后台

后台主要由德龙一个人完成，顶着宜人帮的压力，硬是增加了许多的东西。并且对大部分步骤都进行了分解，防止操作失误。然而加的这些东西也并不是无意义的，最初设计的后台其实是非常简单的，并没有后续的那些功能，咱们做了很多东西，而恰恰就是这些东西让我们还有挽救的余地，让我们能够快速度的应对所有突发的状况。我们这些功能并没有白做，虽然有些功能还没有被用上，但也有幸没被用上...哈哈

当然得感谢德龙，有些东西是我要他加上去的，业务处理我已经写好，需要后台触发一下。

很多东西并不是别人要求你加，其实这是对整个项目的责任，一颗责任心。

小程序

其实最终的小程序，我们是有"圈子"功能的，你可以发现场的视频，图片到圈子里。但在年会前两天微信小程序的审核失败了，已经来不急再次提交审核了。无奈，我们这些功能无法使用，也就只有简单的年会信息及导航了。

这是一个遗憾...

// 此处应有小程序图

尾巴

整个年会办的还是相当不错的，特别是京京姐，实在是太厉害了。

她掌控着年会所有环节，每一个可能出问题的地方都会对操作人员进行提醒。以及一些紧急情况的处理都相当到位。不得不佩服啊她啊。也是我们学习的榜样。

这个年会，我们后台工作人员感受还是相当深刻的，每个人心里都在默默的念:"千万别出问题，千万别出问题"。在南场有近700个人，公司所有同事、领导都在这里，紧张而又刺激。

年会就是一次技术的尝试，通过这门技术的使用情况，压力情况可决定来年是否应该使用这门技术或用这门技术做哪些事情比较好。相信这次年会后我们已经有了一些答案。

这届年会以如何，交给大家评价。我们都已经尽力了...

最后辛苦所有的工作人员了，有你们这届年会才会如此精彩。

期待2017, 腾飞2017。

(本文在回家的火车上完成, 在家由于网络问题发法上传图片，无奈借邻居家wifi一用)