📚 课程目录第3章 A/B分流核心原理

3、A/B分流核心原理：分流策略、灰度发布与风控价值

A/B分流是金融压力测试中实现“同一模型、不同策略”或“同一策略、不同参数”并行验证的关键基础设施。其核心在于稳定、可复现、低偏地将流量分配到不同实验组，并与灰度发布、实时风控形成协同。本节从分流策略、与灰度发布的关系、在风控中的价值三个维度展开。

3.1 分流策略：流量比例、用户维度与随机/哈希算法

分流策略决定了“谁进入实验组A，谁进入对照组B”。金融场景对分流的一致性要求极高——同一用户在一次压力测试周期内必须始终落在同一分组，否则会导致指标污染。

3.1.1 流量比例与用户维度

维度	说明	金融场景典型值
流量比例	实验组与对照组的流量切分百分比，如 50%:50%、10%:90%	压力测试初期常用 5%:95% 或 10%:90% 控制风险
用户维度	按用户ID、设备ID、手机号、身份证号等稳定标识进行分流	优先使用用户ID（user_id）或设备指纹（device_id）
时间维度	按请求时间戳或日期进行分流（较少单独使用，常与用户维度组合）	用于“日级别”压力测试切换，避免日内用户分组漂移

避坑提示：不要使用IP地址或Session ID作为分流维度。IP会因网络切换而变化，Session ID在用户重新登录后重置，均会导致分流一致性失效。

3.1.2 随机分流 vs 哈希分流

两种主流分流算法各有适用场景，金融压力测试中哈希分流是首选。

对比项	随机分流（Random）	哈希分流（Hash-based）
原理	每次请求独立生成随机数，按概率分配	对用户标识（如 user_id）做哈希运算，取模映射到分组
一致性	同一用户多次请求可能落入不同分组	同一用户始终落入同一分组（确定性）
可复现性	不可复现，每次实验需重新随机	完全可复现，相同输入得到相同分组
金融适用性	低（不满足监管审计要求）	高（满足一致性、可追溯、可复现）

哈希分流典型实现（Java伪代码）：

// 使用用户ID + 实验层ID 做一致性哈希
String userId = "user_123456";
String layerId = "pressure_test_v3";
int bucket = Math.abs((userId + "_" + layerId).hashCode()) % 100;
String group = (bucket < 10) ? "experiment" : "control"; // 10%实验组

3.2 分流与灰度发布的关系

分流与灰度发布在金融系统中是互补而非替代的关系。分流解决“如何切流量”，灰度发布解决“如何逐步放量”。

分流是灰度发布的基础能力：灰度发布依赖分流策略将新模型/策略逐步暴露给指定比例的用户。
灰度发布是分流的工程化落地：通过灰度开关、白名单、百分比阶梯，实现从 1% → 5% → 20% → 100% 的渐进式上线。
压力测试中的典型配合：先通过分流将 5% 流量导入“新模型组”，运行 24 小时压力测试；验证无异常后，通过灰度发布将比例提升至 20%，继续观察。

  关键原则：分流策略一旦确定，在单次压力测试周期内不允许动态调整灰度比例。如需调整，应开启新的实验层，避免流量交叉污染。

3.3 分流在风控中的价值

在金融压力测试中，分流不仅是流量分配工具，更是风险隔离与策略验证的核心手段。其价值体现在三个层面：

风险隔离：将高风险新策略限制在实验组内，即使模型失效，也只影响小比例用户，避免全量风险。
策略对比：通过分流实现“同一时间、同一客群、不同策略”的并行对比，消除时间窗口偏差。
实时熔断：当实验组的关键指标（如逾期率、拒绝率）超过预设阈值时，可快速切断分流，将流量全部切回对照组。

风控红线：分流策略必须与实时风控系统联动。实验组若出现“坏账率飙升”或“通过率异常”，应在 30 秒内自动熔断，并将该用户维度标记为“风险实验组”，后续请求直接走对照组兜底策略。

3.4 分流策略选型建议

场景	推荐分流策略	理由
模型压力测试（离线/近线）	用户ID + 一致性哈希	保证同一用户多次请求落在同一分组，指标可对比
实时风控策略验证	设备ID + 时间窗口哈希	设备维度更稳定，时间窗口防止跨日漂移
灰度发布渐进放量	用户ID + 分层哈希（实验层隔离）	支持多实验并行，互不干扰
紧急熔断回滚	动态比例调整 + 白名单覆盖	可快速将实验组流量降为 0%，或指定用户走兜底

  总结：分流策略是金融压力测试的“交通指挥系统”。选对算法（哈希优先）、定好维度（用户/设备）、配好比例（小流量起步），并与灰度发布、实时风控形成三位一体，才能安全、高效地完成模型验证。