记一次微信抽奖活动的设计与实现

因为公司在 Q3 确定了加大在微信生态方面投入的政策,所以产品想出了很多适合在微信环境下开展的活动,用来提高用户的活跃度以及新用户拉新。「抽奖活动」就是这样一种实现。

活动的大体情况是这样的,在微信网页环境下打开,主要页面的功能就是展示,登记,分享。展示包括各种活动信息,比如抽奖规则,奖品,参与的朋友以及获奖名单,登记就是用户参与这个活动,并获得奖券,用来最终的抽奖。然后用户还可以将这个活动分享到朋友圈或者微信好友,而且他的好友可以通过这个链接参与活动。

记一次微信抽奖活动的设计与实现

大家初看起来可能觉得这个非常简单,但在实际实现上并不是那么简单,首先,用户授权,活动的主体公众号必须要获得用户的授权,这个前端通过调用微信的接口活动 code,然后将这个 code 传给后端,然后后端带上 app_key,app_secret 等参数获得用户的 open_id,以此来唯一标识用户,这个调试过程有可能不会很顺利,因此需要先打好日志,获得用户授权以后,那么前后端在每一次交互的时候如何确定用户的身份呢?总不能所有请求带上裸露的 open_id 吧,这样太危险了,我这边的做法时,在第一次授权的时候拿到用户 open_id, 然后使用 AES 和 RSA 加密算法加密 open_id,并传回给前端作为 ticket,然后以后前端在每一次和我交互的时候都要在 headers 里面加上这个 ticket,这样可以极大地提高安全性,因为如果有人修改了这个 ticket ,那么加密算法是解不出来的,就会拒绝这次请求,并且这些操作都是在基类进行的,根本都来不到具体的业务层,然后就是奖券的生成,这个一开始我是准备用毫秒级别的时间戳作为基准来实现,但是发现好像如果并发量很大,这个时间戳也会重复,这样是不符合这次活动的,两个人不能有同样的券码,然后我想到了 redis 的 incr ,它是一个单线程原子操作,不会出现重复,并且这个值可以重建整个获奖券码,在抽奖的时候不需要全量 load 券码,还有一个问题就是当别的用户是通过其他人的链接进来的时候,我们会把这种情况称为助力,这时候就需要唯一区分链接,就是在分享的时候修改链接,将用户的 ticket 作为 url 的一级放到 url 上面,这样就能唯一区分了。数据库我建立了四个表,抽奖表记录每一次抽奖活动的信息,并且有一个特殊的 lottery_id 可以表示某次抽奖,并且这个 lottery_id 是贯穿于整个数据库和代码的,这样就可以支持活动并行了,奖券表,记录每个人获得的奖券,助力表记录助力情况,参与表记录每一次活动的参与情况。并且这个活动涉及到复杂的数据库操作,所以需要使用事务。

一些棘手的问题解决以后,剩下的问题就好弄了,整个的架构是前后端分离的,通过接口来进行交互。大体有这样一些接口,授权接口,助力和参与接口,主页接口等。并且为了支持活动并行,前端也是进行组件化开发。这次的活动主要是我一个人设计编码的,我觉得还比较有意义,所以在此记录,要是能帮到某些人就更好了。

相关推荐