通用裂变-邀请设计

设计需要考虑的要点

1.主态和客态

主态和客态属于在邀请相关的场景下通用的业务名称，主态表示发起邀请的人，客态表示被邀请的人。

2.存储数据

一般的邀请的时候，需要将主态和客态的userId都插入一条数据，这样方便根据主态和客态来查询用户，因为这个邀请的量大的时候，都会需要分表，但是我们的分片数据只能根据一个维度来，所以通过冗余记录的这种方式来保存双向关系。
需要记录主态-客态的类型，方便查询自己的邀请列表、或者被邀请列表的时候，知道自己是邀请人还是被邀请人。


CREATE TABLE `activity_invite`
(
    `id`              bigint       NOT NULL AUTO_INCREMENT,
    `activity_code`   varchar(64)  NOT NULL DEFAULT '' COMMENT '活动编码',
    `tag_code`        varchar(64)  NOT NULL DEFAULT '' COMMENT 'activity_code下的分类：如组队编码',
    `member_id`       varchar(64)  NOT NULL DEFAULT '' COMMENT '用户memberId',
    `refer_member_id` varchar(64)  NOT NULL DEFAULT '' COMMENT '关联用户memberId',
    `refer_type`      int          NOT NULL DEFAULT '1' COMMENT '双向表类别 1：memberId为主态 2：memberId为客态 用于解决分表查询',
    `op_type`         int          NOT NULL COMMENT '邀请类型 1：分享链接 2：扫码',
    `channel`         varchar(64)  NOT NULL DEFAULT '' COMMENT '外投渠道',
    `second_channel`  varchar(64)  NOT NULL DEFAULT '' COMMENT '站内渠道',
    `extra_info`      varchar(512) NOT NULL DEFAULT '' COMMENT '扩展字段',
    `create_date`     timestamp    NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `update_date`     timestamp    NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    `delete_flag`     tinyint      NOT NULL DEFAULT '0' COMMENT '是否删除',
    PRIMARY KEY (`id`),
    KEY               `idx_create_time` (`create_date`),
    KEY               `idx_user_act` (`member_id`,`activity_code`) USING BTREE
) ENGINE=InnoDB  COMMENT='裂变类活动通用邀请或组队表';

3.拓展

为了方便记录组队成功，后续发放奖励的时候，不需要扫描邀请关系表，可以考虑记录一张组队成功表，方便处理，这里可以根据实际的情况不需要分表。

CREATE TABLE `activity_invite_team`
(
    `id`           bigint      NOT NULL AUTO_INCREMENT COMMENT '主键',
    `member_id`    varchar(64) NOT NULL COMMENT '中奖用户id',
    `lottery_code` varchar(64) NOT NULL COMMENT '抽奖活动编码',
    `team_code`    varchar(64) NOT NULL COMMENT '组队编码',
    `delete_flag`  tinyint     NOT NULL DEFAULT '0' COMMENT '是否删除(0:未删除 1:已删除)',
    `create_date`  timestamp   NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `update_date`  timestamp   NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`),
    KEY            `idx_user_id` (`member_id`),
    KEY            `idx_lottery_code` (`lottery_code`)
) ENGINE=InnoDB  COMMENT='活动成功组队表';

4.细节

1.加锁

所有涉及到状态变更的都需要加分布式锁

2.创建队伍 + 加锁

创建队伍时，可以生成一个邀请码（uuid即可），然后和这个用户绑定，分享出去的时候也需要带上这个邀请码

3.加入队伍 + 加锁

1.需要对队伍的编码加分布式锁，防止同一时间超过指定的队伍人数
2.细致的校验，限流等

校验人数，达标则记录一条组队完成，然后做后续处理

3.校验

1.校验编码
2.校验是否已经加入过队伍
3.组队是否已经完成
4.发起队伍的数量是否太多
等等，在这种活动中都需要仔细的考虑这些安全、防刷、边界等问题，才能减少资损等恶性的生产事件