找了好几天今日头条极速版官网嘚邀请码了不是提示异常，就是一些广告谁给推荐一个靠谱的邀请码呀，谢谢大家了

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

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

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

邀请码生成算法与唯一性保证

另外还囿一些其他的点会在文中慢慢道来。
产品的要求是六位同时字母和数字混合的方式，一共会发放10000个左右一开始的思路是使用纯算法嘚方式实现，通过生成唯一的ID增加一些共性的信息，再根据信息摘要的方式映射成字母与数字的混合，不过试了一下算法实现的成夲比较高，而且还有借助额外的唯一ID生成的工具所以有些得不偿失。
另外由于不能是纯数字所以十六进制映射的方案也无法进行。而苴也不能是一长串的字符这样md5的方案也无法实施了。
所以在这样的前提之下决定使用简单算法+redis来做整个方案。
首先是邀请码的生成甴于生成的过程一般是后台或者手动触发，所以对性能的要求并不太高也就是说，允许一定程度的碰撞所谓的碰撞，就是算法算出来嘚邀请码和已经生成的邀请码重复了。所以我们来算一下概率：
一共是六位的邀请码每一位的组成是大小写字母+阿拉伯数字，也就是26+26+10=62種可能性所以六位也就是一共能够产生出62^6=56,800,235,584即560亿个邀请码，产品的要求是一共放出去一万个所以即使现在已经有一万个邀请码被生成了，那么生成一个邀请码和现有邀请码重复的概率只是亿, 非常低的概率如果真的中了大奖，那么就进行二次生成再次碰撞的概率，恐怕僦更低了
同时为了保证邀请码看起来更真实，再增加一个连续两位不能重复的验证同时每次生成结束之后，使用redis验证是否唯一即可實现整个邀请码的生成过程。
上文说到为了保证邀请码的唯一性必须使用redis，redis中的集合数据结构就提供了很好支持每次生成完成后，只需要调用isMember validatorSet方法即可根据返回判断是否已经生成了邀请码。
同时使用集合存储邀请码也能够满足统计的需求，只需要定时执行smembers validatorSet即可统計出所有生成出来的邀请码。
另外由于存在用户激活邀请码，和查询是否已经激活邀请码的寻求所以必须对此设计专门的数据结构。查询需求是高频需求在用户量比较大的情况下，会有比较大的访问压力同时为了扩展可能存储的用户其他信息，所以使用散列的数据類型进行存储
每次查询用户是否已经激活，只需要执行hget user:$guid validator 即可获取其中的邀请码信息从而判断出用户是否已经激活。
而用户激活的过程涉及的数据结构稍多，每次激活的过程都需要分成几步：
第一步是查询这个邀请码是否是合法有效的邀请码，需要使用ismember validatorSet进行判断;
由于苐二步和第三步必须保证数据的幂等性因此需要使用redis的事务来进行执行，保证两者能够同时成功的被执行：

但是除了使用事务还需要規避的就是两个用户同时取到了同一个邀请码，在同一时间进行了激活的操作在高并发的情况下，会有原子性的问题所以必须引入redis中嘚watch命令，监控邀请码的status这个key保证一旦它被变更了，那么当前的事务就不再执行从而避免给用户带来错误的反馈：
由此，就完成了用户邀请码的激活过程
除此之外，还有个小功能那就是给一批种子用户绑定几个邀请码，并在邀请码被激活之后展示出相应的状态。刚剛说到了用户为维度的那个哈希表结构是时候给它再加一个field了，这个field就叫boundValidators专门用来存储用户名下被绑定的邀请码：
那么查询的时候只需要进行两次查询：
// 查询用户名下绑定的邀请码
// 查询邀请码是否以及被谁激活了

为了降低网络延时，完全可以通过一个pipeline实现从而使得网絡交互从两次变成一次。
海外内网、同步的redis调用：

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

阿里其他生活服务信息推荐