用户看个广告，积分怎么分给上10代？裂变关系链的架构设计

一、两种裂变模式的技术本质
裂变营销系统的核心技术挑战不在业务规则本身，而在于关系链的数据结构设计和积分流转的路由算法。本文拆解两种典型裂变模式的技术实现：
模式A：三三复制+广告积分
用户看广告产生积分，积分按"第N个广告→第N代上级"的规则路由到关系链上。每个节点最多直推3人，超出部分自动滑落到下级网络。全程只有积分流转，不涉及资金交易。
模式B：推三返一
用户消费后解锁推广资格，成功推荐3位新用户消费后全额返还首单费用。仅一级直推返利，无层级计酬。
两种模式的技术差异在于：模式A需要维护一棵深度可达10层的三叉树，并实现代际积分路由；模式B只需要一级关系链和返利状态机。本文重点拆解模式A的技术架构，模式B作为对比参照。
二、三三复制的关系树数据结构
2.1 三叉树的存储模型
三三复制的核心约束是：每个节点最多有3个直接子节点。这棵树的存储有两种方案：
方案一：邻接表模型
每个节点记录parent_id和三个子节点指针：
node_id（主键）
parent_id（父节点ID）
child_1_id, child_2_id, child_3_id（三个子节点，可为空）
depth（节点深度，根节点为0）
tree_position（在父节点中的位置：1/2/3）
created_at（创建时间，用于滑落排序）
方案二：路径枚举模型
每个节点记录从根到自身的完整路径：
node_id（主键）
path（如"1.2.3.1"，表示根节点的第2个子节点的第3个子节点的第1个子节点）
depth（路径深度，等于path中".“的数量）
两种方案的权衡：
邻接表模型：写入快（只需更新父节点的child指针），但查询某节点的第N代祖先需要N次查询（逐级查parent_id）
路径枚举模型：查询快（直接从path中截取前N段即可定位第N代祖先），但写入时需要维护path字符串，树结构调整（如节点迁移）代价高
系统采用混合方案：邻接表为主存储（写入性能好），同时在Redis中维护每个节点的祖先链缓存（ancestors_list），用于高频的代际路由查询。祖先链在节点创建时一次性计算并缓存，后续读取只需O(1)时间。
2.2 自动滑落算法
当用户A已直推3人，第4个被推荐人B加入时，系统需要自动将B放置到A的子树中"子节点未满的位置”。滑落规则是"从上到下、从左到右"。
算法流程：
从A节点开始，检查A的三个子节点位置（child_1/child_2/child_3），找到首个空位。如果有空位，B直接填入。
如果A的三个子节点都已满，进入A的子树做广度优先遍历（BFS）。
BFS按层级遍历：先检查A的所有直接子节点（第1层），再检查第2层，依此类推。
在同一层中，从左到右（child_1→child_2→child_3）检查每个节点是否有空位。
找到的首个空位即为B的放置位置。
算法复杂度：最坏情况下需要遍历到第k层才找到空位，遍历节点数为3¹⁺³2+…+3^k。对于10层三叉树，总节点数上限约88573个，但实际滑落时通常在前几层就能找到空位（因为树的不均衡性），平均遍历不超过20-30个节点。
2.3 滑落的并发控制
高并发场景下，多个用户同时推广可能导致滑落竞争——两个人同时推荐到同一个"空位"。
系统采用分布式锁+乐观重试的方案：
滑落算法执行前，对目标子树的根节点加分布式锁（Redis RedLock）
锁持有期间完成空位查找和节点写入
如果获取锁失败，等待200ms后重试（指数退避，最多重试3次）
写入完成后释放锁，下一个滑落请求可以继续
锁的粒度选择子树根节点而非全局锁，确保不同子树的滑落可以并行执行，吞吐量不受单点限制。
2.4 深度限制与截断策略
三三复制树的深度直接影响积分路由的范围。模式A设定深度上限为10层——第10个广告的积分路由给第10代上级。超过10层的节点不再参与积分路由。
深度限制的实现方式：
数据库CHECK约束：depth ≤ 10
应用层校验：滑落算法在BFS遍历时设置最大深度参数，超过10层不再向下搜索空位
如果某子树10层已满，新节点滑落到该子树的其他分支，或标记为"溢出节点"（不参与积分路由，但保留关系链记录）
三、广告积分的代际路由引擎
3.1 广告索引到代际的映射规则
模式A的核心规则：用户观看第N个广告时，产生的积分路由给其第N代上级。
映射关系：
第1个广告 → 第1代上级（直推人，parent_id）
第2个广告 → 第2代上级（parent的parent）
…
第10个广告 → 第10代上级
用户自身的广告计数器独立维护：每个用户有一个ad_counter字段，记录已观看的广告序号。每次观看广告时，ad_counter+1，当前值即为N，决定积分路由给第N代上级。
3.2 积分路由的执行流程
当用户U观看第N个广告时，积分路由引擎执行以下步骤：
读取U的ad_counter，自增得到N
从Redis缓存中读取U的ancestors_list（祖先链）
取ancestors_list的第N个元素，即第N代上级的node_id
如果第N代上级存在（深度足够），生成一条积分流水：source=U, target=ancestor_N, amount=1, type=AD_REWARD
如果第N代上级不存在（U的深度不足N层，即U在树中的深度<N），积分进入"无归属"状态，可配置为销毁或回流到平台池
3.3 反向积分汇聚
上面描述的是"用户看广告给上级送积分"。反过来，下级看广告时积分也会回流到上级。从上级A的视角看，其第K代下级的广告行为会产生积分给A。
但A的第K代下级可能有很多个（三三复制下，第K代有3^K个节点）。A收到的积分数量取决于其第K代下级中有多少人观看了第K个广告。
系统不需要主动推送积分给A——积分路由是"看广告时触发"的。每个下级观看第K个广告时，系统检查其第K代祖先是否为A，如果是则积分路由到A。这是一种拉模式（pull-based）的积分分发，由广告观看事件驱动，不需要遍历A的全部下级。
3.4 积分计数的幂等性
广告观看可能因为网络重试导致重复回调。系统需要确保同一个广告观看事件不会产生多条积分流水：
每次广告观看生成唯一的event_id（广告ID+用户ID+时间戳的哈希）
积分流水表对event_id做唯一索引
重复回调时，INSERT操作因唯一索引冲突而失败，系统捕获异常并忽略
ad_counter的自增使用数据库的原子操作（UPDATE … SET counter = counter + 1 WHERE …），避免并发导致计数跳跃
四、推三返一的返利状态机
4.1 与模式A的架构差异
推三返一模式的技术复杂度远低于三三复制：
不需要维护多叉树，只需要一级parent_id关系
不需要代际路由，返利只在直推关系中发生
不需要滑落算法，推荐人就是直接上级
核心数据模型：
user_id, parent_id（直推人）, purchase_status（是否已消费）, referral_count（成功推荐人数）, refund_status（返利状态）
4.2 返利状态机设计
用户从消费到返本的状态流转：
S0 未消费：用户注册但未购买，无推广资格
S1 已消费待推广：用户完成购买，解锁推广资格，referral_count=0
S2 推广进行中：每成功推荐1人消费，referral_count+1
referral_count=1时，触发阶段返利（如返还10%）
referral_count=2时，触发阶段返利（如返还20%）
referral_count=3时，触发全额返本（剩余70%），进入S3
S3 返本完成：首单费用已全额返还，可配置为继续推广赚纯收益
状态机的关键约束：
只有处于S1或S2状态的用户才能成为推荐人
被推荐人必须完成购买（进入S1）才算"成功推荐"，仅注册不算
referral_count只统计"首次消费"的被推荐人，重复消费不累计
4.3 返利金额的幂等控制
阶段返利（推第1人返10%、第2人返20%、第3人返70%）需要确保每阶段只触发一次：
返利触发基于referral_count的变化，而非事件回调
系统在referral_count从0→1时触发首阶段返利，1→2时触发第二阶段，2→3时触发第三阶段
使用数据库行锁（SELECT … FOR UPDATE）锁定用户记录，确保并发推荐不会导致计数错误
每次返利生成独立的返利流水记录，包含触发时的referral_count值，用于审计
五、积分账本系统设计
5.1 双分录记账模型
模式A的积分流转采用双分录记账法（Double-Entry Bookkeeping），确保积分守恒：
每笔积分变动产生两条记录：
贷记（Credit）：积分来源方（广告观看事件产生的积分，source=AD_SYSTEM）
借记（Debit）：积分接收方（上级用户账户）
积分账本表结构：
entry_id（主键）
transaction_id（交易批次ID，同一次积分路由的两条记录共享）
account_type（来源账户/目标账户）
account_id（广告系统/用户ID）
direction（CREDIT/DEBIT）
amount（积分数量）
event_id（关联的广告观看事件ID）
created_at（时间戳）
双分录确保任意时点的积分总量守恒：所有CREDIT之和 = 所有DEBIT之和。如果出现不一致，说明系统存在bug或数据损坏。
5.2 积分到购物券的兑换
积分不能直接提现，只能兑换购物券。兑换流程：
用户发起兑换请求，指定兑换数量
系统检查用户积分余额是否充足
生成兑换流水：从积分账户DEBIT，到购物券账户CREDIT
购物券设置有效期（如30天），过期自动作废
购物券在合作商户消费时抵扣，商户按抵扣金额与平台结算
兑换汇率固定（如1积分=1购物券=0.187元），汇率基于广告收入拨出比例计算：
单次广告收入：CPM/1000（如220元/1000次=0.22元/次）
平台拨出比例：85%
单次广告产生的积分价值：0.22 × 85% = 0.187元
5.3 无资金池的架构保障
模式A的合规核心是"全程不碰资金"。系统架构层面的保障措施：
系统无充值接口：系统不提供任何资金充值入口，用户账户中只有积分余额，没有现金余额
系统无提现接口：积分只能兑换购物券，不能提现为现金
购物券结算走商户通道：购物券在商户消费时，资金从广告主→平台→商户，不经过用户账户
积分非货币属性：积分在系统中定义为"任务奖励单位"，不是电子货币，不能跨用户转账
这些架构约束从代码层面杜绝了资金池的形成——系统根本不存在处理资金的模块。
六、合规边界检测系统
6.1 层级深度锁
模式A的积分路由深度为10层，但模式B的返利深度为1层。不同模式的层级深度限制不同，系统需要根据模式配置做硬约束。
实现方式：
数据库层：CHECK约束 depth ≤ max_depth（模式A: 10, 模式B: 1）
应用层：积分路由引擎在取第N代祖先时检查N ≤ max_depth
监控告警：如果出现depth超过max_depth的记录，立即告警并阻断
6.2 计酬函数合规检测
传销的法律界定中，“以发展人员数量为依据计算报酬"是核心特征。系统需要证明计酬函数不依赖人头数。
模式A的计酬函数：
f(ad_views) = ad_views × points_per_view × exchange_rate
变量是广告观看次数（劳动行为），不是推荐人数
推荐人数只影响关系链结构（积分路由路径），不直接参与计酬计算
模式B的计酬函数：
f(referral_count) = refund_amount IF referral_count ≥ 3
变量是成功推荐消费的人数，但返利上限为首单费用（非盈利性返利），且仅一级
系统内置计酬函数审计模块，定期检查积分/返利的计算逻辑是否符合上述函数定义，如果发现异常计算逻辑（如出现与人头数挂钩的乘数因子），触发合规预警。
6.3 关系链可视化审计
系统提供关系链可视化工具，支持：
查看任意用户的关系树（最多展示10层）
标注每个节点的积分来源和去向
检测异常结构（如某条链路深度异常、某节点子节点数量超限）
导出关系链数据供合规审查
七、系统整体架构
7.1 架构分层
系统分为六层：
用户接入层：小程序/H5前端，广告展示、积分查看、推广分享
关系链管理层：三叉树存储、滑落算法、祖先链缓存、深度控制
广告任务引擎：广告调度、观看计数、事件生成
积分路由引擎：代际路由、幂等控制、双分录记账
账本结算层：积分账户管理、购物券兑换、商户结算
合规监控层：层级深度锁、计酬函数检测、关系链审计
7.2 技术选型
关系树存储：PostgreSQL（支持递归CTE查询，适合树结构遍历）
祖先链缓存：Redis Sorted Set（按深度排序的祖先列表）
消息队列：Kafka（广告观看事件广播，积分路由异步消费）
分布式锁：Redis RedLock（滑落并发控制）
账本数据库：MySQL（事务支持，确保双分录一致性）
7.3 性能考量
积分路由是高频操作：1万活跃用户 × 10条广告/天 = 10万次/天的积分路由
单次路由延迟目标：<50ms（Redis缓存命中时）
滑落算法低频但耗时：平均遍历20-30个节点，延迟<10ms
账本写入：批量异步写入，每秒可处理1000+条流水
八、常见技术问题
Q1：三三复制的树如果某条链路特别深（10层全满），而其他链路还很浅，滑落会怎么处理？
滑落算法的BFS遍历天然解决了这个问题——它总是找最浅的空位。如果某条链路10层全满，BFS会跳过该链路，在其他更浅的链路中寻找空位。如果整棵树所有链路都达到10层深度（理论上限约88573个节点），新节点将无法放置，系统标记为"溢出”，需要人工介入或开启新树。
Q2：用户看广告的顺序重要吗？如果他先看了第5个广告再看第1个广告，积分怎么路由？
积分路由基于ad_counter的当前值，不基于广告内容。用户每次观看广告（不管哪个广告），ad_counter都+1。第1次观看→第1代，第2次观看→第2代，依此类推。广告内容与积分路由无关，广告系统只负责展示广告，积分路由引擎只关心"这是第几次观看"。
Q3：如果一个用户的上级（第3代）在项目中途退出了（注销账号），他的积分怎么处理？
系统对注销用户的关系链节点做"软删除"——保留节点结构和深度信息，但标记为inactive。积分路由时，如果目标祖先是inactive状态，积分进入"无归属"池。可配置处理策略：销毁、回流平台池、或顺延给下一级活跃祖先。推荐策略是顺延——将积分路由给第N+1代祖先，确保积分不浪费。
Q4：推三返一模式中，被推荐人在3人未满之前退款了，推荐人的referral_count怎么处理？
被推荐人退款后，其purchase_status回退为未消费状态，推荐人的referral_count需要相应减1。如果推荐人已经基于该推荐人触发了阶段返利（如推第1人时已返还10%），需要生成冲销流水，从推荐人后续返利中扣减。系统通过退款事件触发反向冲销流程，确保返利金额准确。
Q5：广告积分的兑换汇率是固定的还是可调的？如果CPM变化了怎么办？
兑换汇率基于CPM和拨出比例计算，两者都是可配置参数。系统支持汇率版本管理：每次参数变更生成新版本，新版本仅对变更后的积分生效，历史积分按变更时的汇率兑换。汇率变更需记录操作日志（变更人、变更时间、旧值、新值、变更原因），支持审计追溯。
Q6：系统如何防止用户刷广告（自动播放、脚本模拟观看）？
广告观看事件的生成需要满足以下条件才算有效：广告播放时长达到完整时长的80%以上、播放期间有随机交互验证（如每15秒弹出的微交互按钮）、设备指纹和IP频率限制（同一设备/IP每小时观看上限）。无效观看不触发积分路由。同时，系统通过观看行为模式分析检测异常——正常用户的观看间隔有随机性，脚本观看通常间隔固定，行为特征检测可识别大部分自动化行为。
九、核心要点总结
裂变关系链系统的架构设计，核心解决三个技术问题：
关系链结构可维护：通过三叉树邻接表+祖先链缓存的混合存储方案，支持高效的滑落放置和代际查询；通过分布式锁解决并发滑落竞争；通过深度限制约束积分路由范围
积分路由可追溯：通过广告计数器到代际索引的映射规则，实现"第N个广告→第N代上级"的精准路由；通过双分录记账确保积分守恒；通过幂等控制防止重复计算
合规边界可检测：通过层级深度锁限制返利层级，通过计酬函数审计证明收益来源于劳动行为而非人头费，通过无充值/无提现的架构约束杜绝资金池形成
两种模式的技术复杂度差异显著：模式A需要维护多叉树、实现代际路由和滑落算法，系统复杂度高但可扩展性强；模式B只需一级关系链和状态机，实现简单但扩展性有限。选择哪种模式取决于业务场景对裂变深度和合规边界的不同要求。
从技术架构角度看，裂变系统的本质是关系链数据结构与价值流转引擎的组合。关系链决定了价值的流转路径（谁给谁），流转引擎决定了价值的计算规则（给多少）。两者解耦设计——关系链模块只负责拓扑维护，不参与价值计算；流转引擎只负责价值计算，不感知关系链拓扑——使系统可以灵活适配不同的裂变规则，而不需要修改底层存储结构。