游戏中的abtest功能实现，演进与复盘

前言

abtest是一种很常见的，利用真实用户来测试的方法。在游戏中，可以用abtest来测试不同的活动，不同的商品，不同的定价，不同的匹配策略等等的用户接受程度。

初版：简单的ab池划分与细分

在接到第一版需求到时候，需求相当简单，策划/运营想要一个可以做abtest的工具，支持细分和多概率组。
基于这个需求，第一版本的abtest需要做三件事情，将玩家的属性统计出来；将玩家按不同的属性进行划分，进而按照不同的概率进行分池；不同业务可以配置在同一个abtest组里面，比如说玩家看到的公告需要和自己看到的商品协同。
在这一阶段：最终实现的abtest方案如下：

1. 配置表设计
   由于需要将不同的业务可以配置到同一个组里面，abtest的配置表被设计成了三张表分离：分别是业务表，abtest表和细分表。这是出于一下考虑：
   a. abtest需要有做到不同业务可以协同测试。所以abtest表独立出来，对开发来说更加直观。
   b. abtest中有组的概念。而同一组中，对应的细分条件是一致的，也就是说，abtest中，相同的组会共用同一个细分条件，同时，不同的组，也有可能共用同一个细分条件。那么将细分纬度再抽离出一个表，是符合程序逻辑的。
   c. 在流程设计中，登陆的时候需要根据abtest的细分条件来生成玩家的标签，因此将细分条件抽出来成表，方便程序实现。
2. 游戏测按照策划的需求，在不同的模块统计用户的行为。在玩家登出的时候进行汇总，形成玩家的属性。
   由于游戏中，玩家的不同属性是分表存储，不同行为会到不同的模块进行处理。如果每次行为都汇总到某一个特定的表或者模块中，则会将这个表/模块变成热点。举个例子，在游戏中，活动模块会接收玩家的各个事件，比如说登陆，对局结算记录，购买，获得，使用物品等事件。那么该模块在整个游戏周边系统就会就会成为一个热点，所有的玩家行为都有可能对该模块发送请求。为了避免abtest也出现这样的情况（毕竟abtest在游戏中不应该成为一个高性能开销的事情），所以采取的方案就是在不同的模块分开统计用户的行为，降低内网的请求量；在登出的时候做统一处理。
3. 在玩家登陆的时候，依照配置表和玩家的属性，生成玩家的标签，作为玩家的基础属性，附带在玩家的请求包中。
   在初版的设计中，考虑的最多的就是降低abtest对现有业务的影响，比如说拉取db所造成的影响。如果是在玩家拉取具体业务的时候进行判断，则需要额外拉取db表，对业务来说会增加时延，同时对业务的改造会比较大。所以考虑的就是将abtest细分条件转为玩家的标签。各个业务只需要判断一下玩家的标签即可。
4. 在玩家获取商店，活动，公告等配置的时候，根据玩家标签和概率，来判断玩家是否命中测试。
   在玩家拉取具体业