因为公司在 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 是贯穿于整个数据库和代码的，这样就可以支持活动并行了，奖券表，记录每个人获得的奖券，助力表记录助力情况，参与表记录每一次活动的参与情况。并且这个活动涉及到复杂的数据库操作，所以需要使用事务。
一些棘手的问题解决以后，剩下的问题就好弄了，整个的架构是前后端分离的，通过接口来进行交互。大体有这样一些接口，授权接口，助力和参与接口，主页接口等。并且为了支持活动并行，前端也是进行组件化开发。这次的活动主要是我一个人设计编码的，我觉得还比较有意义，所以在此记录，要是能帮到某些人就更好了。
