增长实验室-ab分流的流量保护功能介绍 | 京东云技术团队

介绍ab分流的流量保护功能之前，先普及一下ab分流的一些概念和术语

名词解释：

• 实验：用来验证某个决定请求处理方式的功能或策略的一部分流量，通常用来验证某个功能或策略对系统指标（如PV/UV，CRT，下单转化率等）的影响。
• 流量 ：指所有访问用户的请求
• Hash因子：可以理解为访问实验用户的uuid，即一个可以识别某个流量用户的唯一标识。
• Hash算法：是把任意长度的输入通过散列算法变换成固定长度的输出，是一种从任意文件中创造小的数字「指纹」的方法。与指纹一样,散列算法就是一种以较短的信息来保证文件唯一性的标志
• 桶位：ab测试又称为分桶测试。当用户的请求打到某个实验进行分流时，分流引擎会根据请求的uuid + 强一致性hash算法（保证分每个桶分到的越随机越平均越好）生成一个全局固定不变的值 ，然后 值取模100 得到一个0-100区间的具体桶位编号，一个百分点对应一个桶位编号。
• 实验版本：实验版本即实验分组，A/B实验通常是为了验证一个新策略的效果。在实验进行中，所抽取的用户被随机地分配到A组和B组中，A组用户体验到新策略，B组用户体验的仍旧是旧策略。在这一实验过程中，A组便为实验组，B组则为对照组。也有多个实验组和一个对照组构成的实验，他们共同承载了100%的流量请求。

用户桶位编号如何生成

如上图说明，现在大家知道一个用户访问某个实验时都会有一个唯一固定的编号。

为了更好阐述其意，假设我们有这样26位流量用户，分别是A-Z的这样26位用户：

{A , B , C , D , E , F , G , H , I , J , K , L , M , N , O , P , Q , R , S , T , U , V , W , X , Y , Z }

他们访问实验X时，通过 Hash(uid+实验X种子) 生成了如下的实验编号（命名规则为：用户x_桶位编号）：

A\_11,B\_9,C\_12,D\_10,E\_7,F\_9,G\_24,H\_22,I\_18,J\_8,K\_21,L\_15,M\_1,N\_4,O\_76,P\_33,Q_40,

R\_5,S\_12,T\_80,U\_67,V\_25,W\_33,X\_49,Y\_87,Z_100

他们访问实验Y时，通过 Hash(uid+实验X种子) 生成了如下的实验编号（命名规则为：用户x_桶位编号）：

A\_25,B\_17,C\_19,D\_2,E\_1,F\_18,G\_19,H\_22,I\_12,J\_2,K\_22,L\_14,M\_4,N\_16,O\_28,P\_30,

Q\_92,R\_93,S\_8,T\_55,U\_18,V\_100,W\_1,X\_100,Y\_50,Z\_36

通过上面的案例说明，随机的流量用户访问实验时，某些用户生成的桶位编号会一样，那他们就会进入实验的同一个分组里。

实验版本与桶位的关系

一个桶位编号代表全部流量（100%）的一个百分点的流量(1%)

实验分流演示

假设我们一个实验有三个版本即三个分组，分别是 实验组1=VA，实验组2=VB,对照组=VC

初始分组比例为：VA=10%,VB=10%,VC=80%

下一步，我们要将实验组流量扩量，流量分别为：VA=20%,VB=20%,VC=60%

这种扩量后的分流，从分流角度看是ok的，But细心的同学可能会发现之前进入实验组2的用户11-20桶位编号的在进行实验组扩量后，居然...居然...被分配到实验组1。这样就发生了用户跳组的情况，如果接下来继续扩量，一直会存在此类问题：就是进入过实验组2的用户扩量后又被分配到实验组1。

每次都有实验组用户污染的问题，但是运营同事每次调整比例时并不知道后端分配逻辑，他们会想当然认为流量分配是ok的，这种分配方式会造成数据分析问题和用户体验问题，可能比例调整后对其他组的用户进行了污染，这样的结果在业务上是不可接受的

那么... 针对这种情况实际怎么分配会最佳呢，继续往下看。

正确的分流效果图

如上效果图：

VA 版本由原来的10%扩量到20%，正确的分流是：

新增的10%流量来自对照组VC的流量用户即桶位区间是21-30。

扩量后VA的20%流量是由：1-10,21-30的两个桶位区间。

VB版本由原来的10%扩量到20%，正确的分流是：

新增的10%流量来自对照组VC的流量用户即桶位区间是31-40。

扩量后VB的20%流量是由：11-20,31-40的两个桶位区间。

这样的扩量之后不会出现之前那样的流量用户发生跳组，即保证原来的用户进入的哪个版本扩量之后还是之前的版本。

这种的分流优化我们称之为：流量保护，就是我们本篇文章重点介绍的功能。

为什么做流量保护：

答：实验迭代时，增减版本、调整比例是最高频的操作，此时平台采用了【流量保护】功能，即每次修改先识别减少比例的版本，从减少比例的版本的流量拆分给增加比例的版本。最大限度隔离流量，减少实验组之间相互污染；

引入流量保护功能

ab分流亟需解决这种不科学的流量调整问题，升级【流量保护】功能后，再看一组如下实验的版本流量迭代的推演过程（红色代表A组、蓝色代表B组、绿色代表C组）

这样经过多次调整后，每个实验都尽可能的减少了自己区间的变动，保证自己用户的留存性，减少对实验指标的影响

流量保护动画推演

大家可以直接欣赏：四个版本比例调整的推演（可以关注每个版本色块的变化）

从上面的例子可以看出，经过多次的流量调整后，各个实验的区间分布会变得比较复杂，但是从使用者的角度看，他只需要关心每个实验所占的流量配比，不需要关心底层实验流量的区间分布情况(这块对他是黑匣子)，因此不会增加使用者操作的难度。

流量保护分配规则

• 对版本比例调整进行分组：比对版本修改前、后的数据。按序识别比例新增、减少、不变的三个变化组
• 将版本减少组的桶位拆分：对减少组版本桶位区间从最右侧拆分、匹配直到满足减少的浮动比例的桶位区间段
• 对拆分的桶位区间排序、移动：对减少组被拆分的桶位区间按从左到右的排序，依次次分配给新增版本
• 对版本变化后的桶位排序、合并： 分配后的所有版本进行桶位区间排序，相邻的桶位区间进行合并操作

作者：京东科技 付浩军

来源：京东云开发者社区 转载请注明来源