A/B实验系统设计
圈定人群或者流量
圈定人群或者流量功能可以独立出来做灰度发布.人群可以根据白名单、号码包、uid、城市、时间或者自定义等维度做区分分组
分组之后可以写两套代码分别部署于不同的IDC或者服务器,也可以在一套代码中根据分组走不同的逻辑.人群划分之后为了避免多因素影响A/B测试的准确性,一般分组根据流量划分,不可根据城市或者时间段等划分指标统计
根据实验目的统计指标变化置信区间、显著度
实验是否可信
并行A/B系统设计要点
假设线上同时运行成千上万组A/B实验,并且实验之间是各自独立的.为避免实验之间互相影响,有两种做法
- 人群按实验组数划分,但会随着实验组数增加导致人群变少
- 流量划分时在每个实验之间都随机划分, 例如A/B/C三个实验,每个实验分三组,例如A1/A2/A3,B1/B2/B3,C1/C2/C3,UID1-UID999 共999个用户,不能使UID1-UID333同时进入A1/B1/C1,此时B1的效果可能受A1影响,C1的效果也可能受A1/B1影响
流量划分常见策略是根据uid进行hash后对bucket大小取余,因此为了避免并行实验互相影响,每一个实验hash时需要hash(uid,salt).其中每一个实验的salt需要不相同
如何设计高可用
需要配置两地三机房或者异地双活.当一个机房故障时可以切流到其他机房
如何应对大并发
以常见的zookeeper为例,如果每次请求配置都需要执行一次rpc调用,大并发情况下耗费时间是相当可观的.所以最好的策略是将配置下发到本地,通过本地读取.可以通过在机器上边部署client,定期或者触发式去拉取配置.此时client的高可用和监控也需要保证.例如通过supervised保活,监控系统进行监控.
sdk开发
为了方便android/ios/服务端不同语言接入,需要开发sdk,增加接入的便捷度
配置平台
为了方便运营或者开发同学配置灰度发布或者A/B实验,需要增加一个配置平台,配置完毕后可以同步到配置系统