📚 课程目录第4章分流机制设计

4. 分流机制设计

分流机制是A/B实验的“交通枢纽”。规则本身写得再精妙，如果流量分配错了，实验结论就会失真。本节围绕七类分流方式展开，并重点讨论一致性保障这一最容易被忽视、却最影响实验可信度的工程问题。

一、核心原理：分流的本质是“可复现的映射”

分流的本质，是把一个请求（或用户）稳定地映射到某个实验组。这个映射必须满足三个条件：确定性（同一对象每次落入同一组）、均匀性（各组流量比例符合预期）、独立性（不同实验之间互不干扰）。随机分流满足均匀性但难以保证确定性；哈希分流通过固定算法同时满足确定性与均匀性，因此成为工业界主流。

分流的黄金法则：先确定分流维度（用户还是请求），再选择分流算法（随机还是哈希），最后用一致性机制锁定结果。

二、七类分流机制详解

1. 随机分流

每次请求独立随机分配，实现简单，适合对一致性要求不高的场景，如压测流量分配。缺点是同一用户多次请求可能进入不同组，导致体验割裂、指标污染。

2. 分层分流

将流量按业务域切分为多个正交层（如推荐层、风控层、UI层），每层独立实验。层与层之间流量正交，同一用户可同时参与多个实验而不互相干扰。这是支撑大规模实验平台的核心设计。

3. 哈希分流

对分流键（如user_id、device_id）做哈希后取模，映射到实验组。常用算法包括MurmurHash、FNV、MD5截断。哈希分流天然具备确定性和均匀性，是用户维度实验的首选。

# 哈希分流示例（Python伪代码）
import mmh3

def assign_group(user_id, experiment_key, groups):
    # 拼接实验盐值，保证不同实验相互独立
    raw = f"{experiment_key}:{user_id}"
    hash_val = mmh3.hash(raw, signed=False)
    bucket = hash_val % 10000          # 归一化到万分桶
    ratio = bucket / 10000.0
    cumulative = 0.0
    for group_name, weight in groups.items():
        cumulative += weight
        if ratio < cumulative:
            return group_name
    return list(groups.keys())[-1]

# 调用：将用户分为对照组30%、实验组70%
print(assign_group("u_1024", "risk_rule_v2", {"control": 0.3, "treatment": 0.7}))

4. 用户维度分流

以用户为最小单位，保证同一用户在整个实验周期内始终处于同一组。适用于风控策略、推荐算法等需要稳定体验的场景。缺点是实验周期长、样本量增长慢。

5. 请求维度分流

以单次请求为单位分流，样本量增长快，适合短周期、高频次的策略验证。但同一用户可能同时体验新旧策略，需警惕体验不一致带来的指标噪声。

6. 时间窗口分流

按时间段切换策略，如上午跑对照组、下午跑实验组。适合无法同时并行的场景（如全局配置变更），但极易受时段效应干扰，必须配合时间序列分析。

7. 一致性保障

一致性是分流的生命线。核心手段包括：固定哈希盐值、持久化用户分组结果、实验配置版本化管理、分流结果可追溯。任何一次盐值变更或配置漂移，都可能导致用户“跳组”，使实验数据作废。

分流方式	分流维度	一致性	典型场景	主要风险
随机分流	请求	弱	压测、临时灰度	用户体验割裂
分层分流	用户/请求	强	多实验并行平台	层间流量重叠
哈希分流	用户/设备	强	用户级策略实验	盐值变更导致跳组
用户维度分流	用户	强	风控、推荐	样本增长慢
请求维度分流	请求	弱	高频策略验证	指标噪声大
时间窗口分流	时间	中	全局配置变更	时段效应干扰

三、方法流程：从分流键到分组结果

确定分流维度：根据实验目标选择用户、设备或请求作为分流键。
设计实验盐值：为每个实验分配唯一salt，确保实验间正交。
计算哈希桶：对“salt:分流键”做哈希，归一化到万分桶。
映射实验组：按权重区间将桶号映射到对照组或实验组。
持久化与校验：将分组结果写入缓存或配置中心，并提供一致性校验接口。

四、案例场景：风控规则A/B实验的分流设计

某支付风控团队要验证新版规则对欺诈拦截率的影响。实验目标要求同一用户在整个实验周期内体验一致，因此选择用户维度哈希分流。分流键为user_id，实验盐值为“risk_rule_v2_202406”，对照组30%、实验组70%。

# 分流配置示例（YAML）
experiment:
  key: risk_rule_v2_202406
  salt: risk_rule_v2_202406
  dimension: user_id
  groups:
    control:
      weight: 0.30
      rule_version: v1
    treatment:
      weight: 0.70
      rule_version: v2
  consistency:
    cache_ttl: 86400
    persist: true
    version: 20240601

上线后监控发现，实验组欺诈拦截率提升2.3个百分点，但误拦截率也上升0.8个百分点。团队通过一致性校验接口确认无用户跳组，排除了分流问题，最终定位为规则阈值过严，随后调整阈值重新实验。

五、误区与复盘

误区一：盐值随意变更。实验中途修改salt会导致大量用户跳组，实验数据前后不可比。盐值必须与实验版本绑定，变更即视为新实验。

误区二：忽略分流键缺失。当user_id为空时，若直接哈希空值，所有匿名用户会落入同一组，造成严重偏差。必须为缺失键设计降级策略，如使用device_id或随机UUID。

误区三：分层分流未做正交校验。多层实验若共用同一哈希空间，流量会重叠而非正交。应通过不同salt或独立哈希空间保证层间独立。

复盘建议：每次实验上线前，用历史流量做一次分流模拟，检查各组样本量偏差是否在±1%以内；实验期间每日校验用户跳组率，超过0.1%立即告警。

分流机制设计没有“一招鲜”。用户维度哈希分流适合稳定性要求高的风控场景，请求维度分流适合快速迭代的策略验证，分层分流则是大规模实验平台的基石。真正决定实验成败的，往往不是算法本身，而是对一致性细节的持续守护。