邀请业务设计

邀请业务设计，包括数据库设计、后端业务逻辑设计、前端业务逻辑设计

简述

应裂变等营销需求，很多平台都有邀请制拉新的需求。通过邀请形式的推荐机制，辐射不同用户的熟人网络，拉新平台用户，提高平台活跃度和转化率。

设计邀请，邀请串、邀请码、邀请链接都需要直接或间接记录邀请人信息，然后隐藏地提交邀请人标识到后端，数据库绑定邀请人和被邀请人信息，业务层对邀请人执行奖励事件等。

数据库设计

数据库只设计一张用户表，因为邀请人和被邀请人是一对多的关系，且邀请人信息表和被邀请人信息表一样，都是用户表，所以直接把邀请人ID合并到用户表，新建邀请人字段，用最终的用户表即可实现数据结构需求。

用户表结构如下：

属性名	备注
用户ID	被邀请人用户ID，必填，主键ID。也作一般用户ID，是所有用户的唯一标识。
用户基本信息	用户所有的基本信息，实际使用中用多个属性表示
邀请人用户ID	邀请人用户ID，如用户不存在邀请人，填空或0等，否则填邀请人真实ID。邀请人用户ID和用户ID是一对多的关系，一个邀请人可以邀请多个被邀请人，一个被邀请人只能被一个邀请人邀请。邀请人用户ID包含于用户ID，否则非法。

后端业务设计

1. 生成邀请码，不考虑邀请串的场景，主要是针对邀请二维码和邀请链接场景，邀请链接需要包含邀请用户的ID，通过param参数形式追加到链接。
2. 用户ID建议设置加密，不使用真正的用户ID。可以对用户ID加解密，也可以做用户ID的复杂映射代替。
3. 若使用加解密方式，可以在过滤器中进行解密，解密为原始数据再追加到链接上；也可以在接口层做处理，解密为原始用户ID，再进行后续业务。
4. 如果请求带有用户ID的，正常解密，然后存储MySQL。

前端业务设计

1. 浏览器打开链接，获取链接参数，临时存储参数，当用户关闭浏览器时失效。
2. 用户注册，带上邀请人参数发送到后端。
3. 如果用户关闭了浏览器，又直接打开浏览器注册，而没有走邀请链接注册，将不能记录到邀请人信息。要记录，可以设置链接参数临时存本地，这样再次打开浏览器也可以获取到邀请人信息。链接参数存本地的时间可以设置为24h。其中，需要提醒用户，一定走邀请链接去注册，一次性完成操作，这才是最保险的。