金融级A/B测试需以split_clients为骨架，通过双因子哈希、异步热更新、保底兜底和闭环验证实现无损、可复现、低延迟、强一致性分流。
在金融级 A/B 测试中，流量切分必须满足无损、可复现、低延迟、强一致性四大要求。OpenResty 的 split_clients 指令天然适合做客户端维度的确定性分流，但默认同步执行、不支持动态权重更新、无法与业务上下文（如用户 ID、设备指纹、风控等级）联动，直接用于金融场景存在风险。关键在于：用它做底层分流骨架，再叠加轻量级异步增强层，实现“配置即生效、切分即精准、变更无抖动”。
基于 client\_ip + user\_id 双因子哈希的确定性分流
金融场景严禁因客户端重连、代理透传或 header 伪造导致同用户跨实验组漂移。split_clients 默认仅依赖 $remote_addr，易受 NAT、CDN 回源影响。应主动构造稳定哈希键：
- 优先取请求头中可信的
X-User-ID（经鉴权服务签发，不可篡改），fallback 到$remote_addr+$http_user_agent组合哈希 - 使用
ngx.sha1或ngx.crc32_short计算哈希值，再对总实验组数取模，确保分布均匀（避免用简单字符串截取） - 示例配置中，将
split_clients的输入变量设为自定义变量$ab_key，而非原生变量
异步加载实验配置，避免 reload 引发的流量抖动
金融系统不允许因修改 AB 配置触发 Nginx reload —— 会中断连接、丢请求、破坏事务一致性。必须绕过 reload，走运行时热更新：
- 用
lua_shared_dict声明全局配置缓存（如ab_config 10m），由独立 Lua Worker 定期（如每 5 秒）从 etcd/Consul 拉取最新实验规则 -
split_clients本身不支持动态权重，因此将其降级为“桶号分配器”：只负责把请求映射到 0~999 的整数桶；真实实验组归属由 Lua 脚本查共享字典中的bucket → group映射表决定 - 映射表结构示例：
{"exp_pay_v2": {"0-199":"control","200-399":"treatment_a","400-999":"treatment_b"}}，支持秒级生效且零中断
按业务维度保底兜底，防止长尾流量漏出
即使做了双因子哈希，仍存在小概率哈希碰撞、header 缺失、风控拦截后未打标等情况。金融系统必须保证 100% 流量有明确归属：
- 在 Lua 阶段设置 fallback 分流逻辑：若
$ab_key为空或哈希失败，则按时间戳毫秒末位、或请求 UUID 后 3 位做保底分桶 - 所有分流结果必须写入 access_log 的自定义字段（如
ab_group=$ab_group），并实时上报至监控系统，确保可审计、可回溯 - 对高敏感接口（如资金扣减、合约签署），强制走 control 组，通过白名单配置在共享字典中隔离，不参与任何自动分流
验证分流精度与一致性，拒绝“看起来像随机”
金融级切分不是“大致符合比例”，而是“每个 1000 请求中，A 组严格等于 300±1”。需闭环验证：
- 用离线日志抽样（如每 1% 请求打 trace_id 标签），统计各实验组实际占比，误差 >0.3% 即告警
- 对同一用户 ID，在 24 小时内多次请求必须始终命中同一组 —— 抽取 10 万用户 ID 模拟压测，验证命中一致性达 100%
- 在灰度发布阶段，将新实验组流量先固定映射到特定 IP 段（如办公网出口），人工验证逻辑正确后再放开全量
不复杂但容易忽略：真正的金融级 AB 不是技术堆砌，而是把“确定性”刻进每一行配置和每一次哈希计算里。split_clients 是锚点，不是终点。
