用户生成邀请码的通用解决方案

随笔 2019-11-20 380 次浏览 次点赞

起步

为用户生成邀请码的通用解决方案,其他项目若也有此需求可以考虑此处的方案。

要求:

  1. 长度不能太长,方便用户的输入,此处以8位为例;
  2. 每个用户一个邀请码,且确保唯一性;
  3. 不易伪造,不能让用户从邀请码上轻易的看出生成的规则;
  4. 必要时可逆推,可以根据邀请码进行反向推导;
  5. 高效性,生成邀请码的算法不能太复杂;

方案

已知用户表已有自增id字段,该字段已确保了唯一性。因此可以考虑从id改造为邀请码,具体改造如下:

  1. 将用户的id转为以16进制表示的字符串,如 180 =》 'b4';
  2. 补位至要求的长度,如上一步 'b4' 补上六位字符随机字符;
  3. 随机字符可以是从 g~z 中获取(或其他不是 0~f 字符);

最大的邀请码数

受邀请码长度的限制,本例子可以产生最多 4294967296 (16的8次方)个邀请码,已相当于32整型的最大值了,大多数情况下够用。

如需要更多数量,也可以在此基础上进行扩充,最直接的方式就是扩大进制: id可以转成32进制再进行补位,那么最多能产生 1099511627776 (32的8次方)个邀请码。甚至可以转成64进制再补位。

甚至必要时,将邀请码位数进行扩充,比如变为10位或更多位。

多进制转换共存

如果是先用16进制转换的后续发现不够用,还能使用扩大进制的方式吗?

可以的。保持旧用户邀请码不变。当有新用户时,以新用户id转32进制。设置邀请码为:前缀 + 32进制 + 补位。前缀可为出 0~f 外的某个字符即可。

一些后续改进建议

用户ID暴露在邀请码中?

如果业务对用户ID比较敏感。那么可以先用ID做个hash。也可以把ID隔位插入。

用户量多的时邀请码变成容易伪造?

伪造容易度受补位长度影响。随着用户的增长且邀请码长度受限,变得容易伪造难以避免。最直接的方式就是扩大进制转换了。

判断验证码合法性

一般情况下,验证码在数据库中存在则视为合法。如何高效校验邀请码的合法性?可以数据库该字段设置索引来提高查询效率;也可以在生成将邀请码时将最后2位作为校验位,取前面6位邀请码模256的值,这样能大概率判断出是误操作而不需要查询数据库。


本文由 hongweipeng 创作,采用 署名-非商业性使用-相同方式共享 3.0,可自由转载、引用,但需署名作者且注明文章出处。

赏个馒头吧