小而美的邀请码设计实现方案

互联网公司推出新产品的时候,经常使用邀请码作为一种运营手段,在一定的时间内,只有具有邀请资格的用户,才能参与到早期产品的体验中去。
这么做,一方面为了体现产品体验的稀缺性,鼓励用户抢购,造成供不应求的舆论影响。这点小米做的尤为突出,效果也是相当不错的。另一方面,先让一部分比较有热情的早期种子用户进来,也能够充分的对产品的易用性和体验流程进行早期的验证,方便手机用户的反馈之后迭代修改。·

我们首先来看看根据需求邀请码服务需要提供出哪些接口:

  • 单个或批量的生成邀请码,要求六位,数字与字符的混合,供运营和用户使用;
  • 给用户激活邀请码;
  • 校验用户是否已经激活邀请码;
  • 批量给已注册用户绑定几个可用的邀请码,方便二次传播;
  • 查询用户名下已经绑定的邀请码和其被激活的情况,验证二次传播的效果

根据需求,现有的技术实现方案有很多,核心来讲的话主要有两点:

  • 邀请码生成算法与唯一性保证
  • 邀请码高效查询与激活

另外还有一些其他的点,会在文中慢慢道来。

邀请码的生成方式

产品的要求是六位,同时字母和数字混合的方式,一共会发放10000个左右。一开始的思路是使用纯算法的方式实现,通过生成唯一的ID,增加一些共性的信息,再根据信息摘要的方式,映射成字母与数字的混合,不过试了一下,算法实现的成本比较高,而且还有借助额外的唯一ID生成的工具,所以有些得不偿失。
另外由于不能是纯数字,所以十六进制映射的方案也无法进行。而且也不能是一长串的字符,这样md5的方案也无法实施了。

所以在这样的前提之下,决定使用简单算法+redis来做整个方案。
首先是邀请码的生成,由于生成的过程一般是后台或者手动触发,所以对性能的要求并不太高,也就是说,允许一定程度的碰撞。所谓的碰撞,就是算法算出来的邀请码,和已经生成的邀请码重复了。所以我们来算一下概率:
一共是六位的邀请码,每一位的组成是大小写字母+阿拉伯数字,也就是26+26+10=62种可能性。所以六位也就是一共能够产生出62^6=56,800,235,584即560亿个邀请码,产品的要求是一共放出去一万个,所以即使现在已经有一万个邀请码被生成了,那么生成一个邀请码和现有邀请码重复的概率只是10000/560亿, 非常低的概率,如果真的中了大奖,那么就进行二次生成,再次碰撞的概率,恐怕就更低了。

同时为了保证邀请码看起来更真实,再增加一个连续两位不能重复的验证,同时每次生成结束之后,使用redis验证是否唯一,即可实现整个邀请码的生成过程。

数据结构的设计

上文说到为了保证邀请码的唯一性,必须使用redis,redis中的集合数据结构就提供了很好支持。每次生成完成后,只需要调用isMember validatorSet方法,即可根据返回判断是否已经生成了邀请码。

同时使用集合存储邀请码,也能够满足统计的需求,只需要定时执行smembers validatorSet,即可统计出所有生成出来的邀请码。

另外,由于存在用户激活邀请码,和查询是否已经激活邀请码的寻求,所以必须对此设计专门的数据结构。查询需求是高频需求,在用户量比较大的情况下,会有比较大的访问压力。同时为了扩展可能存储的用户其他信息,所以使用散列的数据类型进行存储。
每次查询用户是否已经激活,只需要执行hget user:$guid validator 即可获取其中的邀请码信息,从而判断出用户是否已经激活。

而用户激活的过程,涉及的数据结构稍多,每次激活的过程,都需要分成几步:
第一步是查询这个邀请码是否是合法有效的邀请码,需要使用ismember validatorSet进行判断;
如果合法有效,第二步是设置用户的激活状态,即上文中所用到的这个散列hset user:$guid validator {$validator};
第三步则是设置邀请码本身的状态,即这个邀请码被哪个用户用了,方便之后查询 set validator:{$validator}:status {'userName':ted,'avatar':'http://test.com'}

由于第二步和第三步必须保证数据的幂等性,因此需要使用redis的事务来进行执行,保证两者能够同时成功的被执行:

1
2
3
4
$redis->Multi()
->set validator:{$validator}:status {'userName':ted,'avatar':'http://test.com'}
->hset user:$guid validator {$validator}
->exec()

但是除了使用事务,还需要规避的就是两个用户同时取到了同一个邀请码,在同一时间进行了激活的操作,在高并发的情况下,会有原子性的问题。所以必须引入redis中的watch命令,监控邀请码的status这个key,保证一旦它被变更了,那么当前的事务就不再执行,从而避免给用户带来错误的反馈:
redis->watch validator:{$validator}:status

由此,就完成了用户邀请码的激活过程。

除此之外,还有个小功能,那就是给一批种子用户绑定几个邀请码,并在邀请码被激活之后,展示出相应的状态。刚刚说到了用户为维度的那个哈希表结构,是时候给它再加一个field了,这个field就叫boundValidators,专门用来存储用户名下被绑定的邀请码:
hset user:$guid boundValidators $validator1|$validator2...

那么查询的时候只需要进行两次查询:

1
2
3
4
// 查询用户名下绑定的邀请码
hset user:$guid boundValidators
// 查询邀请码是否以及被谁激活了
mget $boundValidators

为了降低网络延时,完全可以通过一个pipeline实现,从而使得网络交互从两次变成一次。

接口性能验证

由此已经大功告成,简单的使用wrk测试一下性能,服务器相比之前的差一些,一共是4核16G内存。使用wrk -t12 -c100 -d10s http:ip:port/queryActivate
海外内网、同步的redis调用:
Alt text

QPS在5000左右,完全满足了本次邀请码的需求,事实上,如果能超过这个量,估计睡觉都要笑醒了:)

热评文章