介绍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组）
这样经过多次调整后，每个实验都尽可能的减少了自己区间的变动，保证自己用户的留存性，减少对实验指标的影响
流量保护动画推演
大家可以直接欣赏：四个版本比例调整的推演（可以关注每个版本色块的变化）
从上面的例子可以看出，经过多次的流量调整后，各个实验的区间分布会变得比较复杂，但是从使用者的角度看，他只需要关心每个实验所占的流量配比，不需要关心底层实验流量的区间分布情况(这块对他是黑匣子)，因此不会增加使用者操作的难度。
流量保护分配规则
- 对版本比例调整进行分组：比对版本修改前、后的数据。按序识别比例新增、减少、不变的三个变化组
- 将版本减少组的桶位拆分：对减少组版本桶位区间从最右侧拆分、匹配直到满足减少的浮动比例的桶位区间段
- 对拆分的桶位区间排序、移动：对减少组被拆分的桶位区间按从左到右的排序，依次次分配给新增版本
- 对版本变化后的桶位排序、合并： 分配后的所有版本进行桶位区间排序，相邻的桶位区间进行合并操作
作者：京东科技 付浩军
来源：京东云开发者社区 转载请注明来源