背景

在事实的产品设计场景中以及业务决策中，须要对计划进行决策。例如，App 或网页端某个页面的某个按钮的色彩是用蓝色还是红色，是放在右边还是左边？传统的解决方案通常是个体表决或由某位 Leader 拍板，相似的抉择还有很多，从概率上很难保障传统的抉择策略每次都是无效的，而 ABTest 显然是一种更加迷信的办法。

业务价值

研发视角

• 先验性：采纳流量宰割与小流量测试的形式，先让线上局部小流量用户应用，来验证咱们的想法，再依据数据反馈来推广到全流量，缩小产品损失。
• 并行性：咱们能够同时运行两个或两个以上版本的试验同时去比照，而且保障每个版本所处的环境统一的，这样以前整个季度能力确定要不要发版的状况，当初可能只须要一周的工夫，防止流程简单和周期长的问题，节俭验证工夫。
• 科学性：统计试验后果的时候，ABTest 要求用统计的指标来判断这个后果是否可行，防止咱们依附经验主义去做决策。

PM 视角

• 试验流程化，系统化，升高用户应用数据产品的门槛
• 数据分析可视化，将通用指标系统化剖析，升高手工剖析频率；对试验后果做到智能解读，间接给出用户数据分析后果，升高用户数据了解门槛

外围概念

1. 场景
   对应业务场景，场景之间齐全独立，比方首页举荐瀑布流、金刚位等。
2. 桶
   从属于场景，一个场景能够有多个桶，一个桶中能够多个试验，不同的桶之间流量是互斥的。
3. 层
   一类（种）试验的汇合，从属于场景，一个场景能够有多个层，处于同一层的各试验之间流量互斥，各试验流量之和为总流量，处于不同层的各试验之间流量正交。
4. 试验
   用来验证某个决定申请解决形式的性能或策略的一部分流量，通常用来验证某个性能或策略对系统指标（如 PV/UV，CRT，下单转化率等）的影响。
5. 流量
   指所有用户申请。
6. 流量正交
   不同层之间流量调配形式齐全独立，不会相互影响 MECE。

试验建模

这里咱们将用户流量分成了三份，分层桶、小流量桶和基准桶。其中：

• 层和桶的数量反对扩大（实践上反对任意多个）
• 层和桶之间没有关联关系
• 试验处于层和桶的穿插部位
• 每一层的 hash 因子不同（通过加盐实现）
• 每一层和桶的穿插部位有一个基准试验，当没命中试验（流量没有齐全利用）时，走基准试验

  分层桶相似于“测试环境”，由算法方较为自在的验证一些想法，因而管控比拟松，在分层桶里咱们容许多个实验组穿插的去验证不同的策略通路，以此来筛选更优的算法组合模式，如果某种组合模式通过初步验证，产生了更好的指标，就能够进入小流量桶。

  小流量桶相似于“预发环境”，咱们将这个组合模式独自灌入新的一批流量，相当于排除烦扰，再次 double check 下，如果的确产生了更好的指标，咱们将其晋升为基准桶。

  基准桶相似于“生产环境”，作为一种稳固的算法策略继续应用。

分流算法

进行分流算法的目标是将线上用户依照固定的流量比例调配到不同试验 (桶) 中，并且放弃这种试验 (桶) 分配关系，以此来对照验证相干的指标是否有所恶化，所以为了放弃这种用户和试验 (桶) 的分配关系，咱们应用了 hash 取模的形式将一个用户固定在了一个 0 到 100 的区间中，这样只有对应试验 (桶) 的区间没有变动，这个用户和试验 (桶) 的分配关系就不会变动。

所以咱们的做法就是将每个试验 (桶) 的流量占比调配到一个 0 到 100 的区间中，依据用户 id 和每一层不同的 hash 因子组合进行 hash，而后取模，余数落到哪个区间就取蕴含该区间的试验(桶)。

如上图所示，A 试验流量占比 30%，B 试验 30%，C 试验 40%，将它们调配到 0 到 100 的区间中，即 A 试验占[0,30)，B 试验占[30,60)，C 试验占[60,100)，计算一个用户模为 50 则命中 B 试验。

如果不须要进行流量调整，这种模式可能很稳固的运行并且放弃这种试验 (桶) 流量分配关系，然而如果进行流量调整，就会存在一些问题，比方此时咱们将 A 试验缩小 15%，B 试验不变，C 试验减少 15%，则 A 试验占[0,15)，B 试验占[15,45)，C 试验占[45,100)，因为每个层的 hash 因子不变，雷同的用户申请产生雷同的模数，最初模为 50 会落入 C 试验的区间，如下图：

这样的后果在业务上是不可承受的，因为 A 和 C 试验流量的调整对 B 试验的用户进行了净化，导致本应该属于 B 试验的一部分用户却走到了试验 C 中，所以在这里咱们进行一些调整，每次流量的调整只会调整它的邻边，即尽可能的缩小流量调整对试验区间重新分配带来的影响，咱们以上图的场景为例，进行改良后的 AB 算法的拆解。

如上图，算法第一步是优先在本人的区域内进行抉择，A 试验流量调整为 15%，从本人的区域 [0,30) 中选取[0,15)，B 试验放弃[30,60)，C 试验因为流量调整为 55%，先把本人的区域选满，即[60,100)。

第二步是填补间隙，C 试验因为还有 15% 没有填补，就把间隙 [15,30) 补上。

这样调整后，A 和 C 试验的流量调整不会给 B 试验带来影响，原先 B 试验的用户调整后仍然还是走 B 试验。而后还能让流量调整后原来 A 试验中的一半用户持续留存在 A 试验中，C 试验原来的用户仍然还是走 C 试验，尽可能减少了用户集变动给试验 (桶) 最终成果带来的影响。

依此类推，如果持续对上述试验集进行流量调整，A 试验调整为 25%，B 试验调整为 35%，C 试验调整为 40%，进行算法的拆解，如下图：

第一步是优先在本人的区域内进行抉择，A 试验因为流量调整为 25%，先把本人的区域选满，即 [0,15)，B 试验调整为 35%，也是优先把本人的区域选满，即[30,60)，C 试验调整为 40%，从本人的区域中抉择[15,30) 和[60,85)。

第二步填补间隙，A 试验因为还有 10% 没有填补，就把间隙 [85,95) 补上，B 试验因为还有 5% 没有填补，就把间隙 [95,100) 补上，最终造成上图的区间散布。

这样通过屡次调整后，每个试验都尽可能的缩小了本人区间的变动，进行相应的“多退少补”，保障本人用户的留存性，缩小对试验指标的影响。

从下面的例子能够看出，通过屡次的流量调整后，各个试验的区间散布会变得比较复杂，然而从使用者的角度看，他只须要关怀每个实验所占的流量配比，不须要关怀底层试验流量的区间散布状况(这块对他是黑匣子)，因而不会减少使用者操作的难度。

零碎设计

AB 平台在零碎设计上尽可能的缩小了内部依赖和 IO 调用，将解决都尽量放在了本地内存中，如下图：

仅依赖了配置核心和数据库，而后上游流量的申请进入 AB 获取试验决策全部都是本地内存操作。其中重载配置过程如上图所示。

• 后盾用户编辑试验信息(①)
• 进行相应的增删改操作批改 DB(②)
• 触发公布一个动态配置，如果该配置已存在则配置值加一(③)
• 配置核心将该配置推送给所有 AB 机器(④)
• 触发所有机器从新加载数据库配置进本地缓存(⑤)

这样上游的申请进入任意一台机器都是在本地内存进行解决，并且每台机器都是加载的最新的配置，大大提高了 AB 平台的解决能力升高了 rt。

零碎设计没有银弹，之所以这样设计是因为 AB 平台具备如下的特点:

1. 弱一致性

依赖配置核心推送随着订阅机器的减少肯定会有一些提早，然而用户批改试验配置后对于即时失效并不是特地敏感，提早几秒都是能够承受的。

2. 缓存内容较少

自身试验的配置信息就比拟少，哪怕将来试验数量达到万量级，单机内存中都齐全足够寄存。

3. 读多写少

用户批改试验配置的次数远远小于上游调用 AB 平台获取决策的次数，所以对于配置核心的调用压力足够小，是在可预期范畴内。

这样设计也存在一些缺点:

1. 数据库毛刺

随着机器数量的减少，用户每次批改试验配置后，所有机器都须要从新加载数据库配置进入本地缓存，每台机器都要触发场景、桶、层、试验、白名单等等的数据库查问，而且是所有机器霎时一起的查问，在机器数达到百台千台以上的时候会对数据库造成较大的刹时查问压力，造成查问超时甚至是更重大的问题，不过能够通过一些形式去缓解:

• 随机工夫期待，每台机器在收到配置变更后随机期待一个短暂的工夫将所有机器加载数据库的工夫点错开一些。
• 数据库缓存，每次批改完数据库后都被动的触发一次缓存加载，不过这里缓存要审慎应用，如果触发缓存加载失败，此时去触发配置核心推送，机器会加载到脏数据导致试验配置批改没有失效，所以批改数据库和被动触发缓存加载肯定要在一个事务中。
• sql 优化，每次从新加载所有配置信息自身 sql 不简单，加索引带来的晋升也不是特地提效，因为配置信息达到 MB 级别的时候，对于网络开销也是较大的，而后机器数量下来后，网络 IO 吞吐会很大，所以能够批改为查问最近一段时间内发生变化的配置信息，这样能够大大减少查问的压力。当然如果将推送版本号改为推送批改的 id 而后独自加载 id 也是可行的，不过要思考到多个用户并发批改不同的试验配置导致配置核心合并配置带来的推送失落问题，之所以推送版本号也是思考到这个问题。

2. 推送效率

随着订阅机器数的减少，推送 rt 的减少是必然的，当然这个缺点是在可承受范畴内的。

3. 僵尸节点

如果机器因为网络问题失联导致配置项推送失败会造成试验配置批改没有齐全失效的问题，会造成一些诡异的景象，不过概率较低，只能依赖运维平台的各种端口检测来提前发现解决。

文|尉迟繁缕

关注得物技术，携手走向技术的云端