3. 用户ID分桶策略：基于user_id的哈希分桶实现与优缺点

好，我们进入分桶方案里最基础、也最常用的一招——用户ID哈希分桶。

说白了，就是把用户的唯一标识（比如 user_id）扔进一个哈希函数，算出一个整数，再对桶数取模，决定这个用户落在哪个实验桶里。听起来很简单对吧？但这里面的坑，我踩过不少。

3.1 为什么选 user_id 做分桶键？

你可能会问：为什么不用设备ID、会话ID或者随机数？

我个人习惯首选 user_id，原因有三：

• 稳定性：用户登录后 user_id 不变。今天分到A桶，明天还是A桶。用户体验一致，不会出现“上午看到新功能，下午没了”的诡异情况。
• 可解释性：出了问题，直接查 user_id 就能定位到桶。不用绕弯子。
• 业务对齐：大部分推荐系统的核心指标（留存、转化、时长）都是按用户维度统计的。分桶和统计口径一致，分析起来省心。

当然，也有例外。比如你做的产品不需要登录，那 user_id 可能为空。这时候就得退而求其次，用设备ID或者cookie。但只要有登录场景，我建议优先用 user_id。

3.2 哈希分桶的核心实现

实现其实就三步：选哈希函数、算哈希值、取模分桶。

我直接给一段伪代码，你一看就明白：

def hash_bucket(user_id: str, num_buckets: int) -> int:
    # 1. 将 user_id 转为字节
    user_bytes = user_id.encode('utf-8')
    
    # 2. 计算 MD5 哈希（也可以用 SHA256，看需求）
    hash_obj = hashlib.md5(user_bytes)
    hash_hex = hash_obj.hexdigest()
    
    # 3. 取前8位转成整数
    hash_int = int(hash_hex[:8], 16)
    
    # 4. 取模得到桶号
    bucket_id = hash_int % num_buckets
    
    return bucket_id

嗯，这里要注意：不要直接用 Python 内置的 hash() 函数。为什么？因为 Python 的 hash() 在进程重启后可能变化，而且不同版本的 Python 实现也不一样。我早期一个项目就吃过这个亏——上线后每次重启服务，用户分桶全乱了。

所以，一定要用确定性哈希，比如 MD5、SHA256。这些算法输入相同，输出永远相同。

3.3 分桶的两种常见模式

实际工程里，我见过两种主流做法：

模式	做法	适用场景
全域分桶	所有用户对 1000 个桶取模，每个实验分配一段连续的桶区间	多实验并行，需要复用同一套分桶逻辑
独立分桶	每个实验单独对 user_id 哈希取模，桶数独立	实验少、互斥性强，不想维护全局桶分配表

我个人更推荐全域分桶。为什么？因为后期扩展实验时，你不需要改代码。只要在配置中心里声明“实验A占用桶1-100，实验B占用桶101-200”就行。我曾经在一个项目里用独立分桶，结果上了20个实验后，配置表乱成一锅粥，排查问题花了整整两天。

3.4 哈希分桶的优缺点

任何方案都有两面性。我直接给你列个表，清晰一点：

维度	优点	缺点
均匀性	好的哈希函数（如 MD5）能保证用户分布基本均匀，偏差通常在 1% 以内	如果 user_id 本身有规律（比如全是连续数字），取模后可能出现小偏差
稳定性	用户分桶结果不随时间、环境变化	一旦桶数固定，扩缩桶会导致所有用户重新分桶（这就是“哈希分桶的硬伤”）
实现成本	代码简单，几行就能搞定	没有内置的流量调控能力，不能按比例动态调整
可扩展性	支持任意数量的桶，理论上无上限	桶数变化时，历史数据对比会受影响

3.5 避坑指南：我踩过的三个坑

做推荐系统这些年，我在哈希分桶上栽过好几次。挑三个典型的跟你说说：

1. 坑一：哈希碰撞导致桶分布不均

   我曾经用了一个简单的 CRC32 做哈希，结果发现某些桶的用户数比其他桶多了 5%。排查后发现，CRC32 的碰撞率在特定 user_id 格式下偏高。后来换成 MD5，问题就解决了。

   建议：生产环境用 MD5 或 SHA256，别图省事用轻量级哈希。

2. 坑二：桶数变化导致实验污染

   有一次，我们把桶数从 100 改成 200，结果所有用户的分桶都变了。实验组和对照组的用户群体完全打乱，之前积累的 A/B 测试数据全废了。

   建议：桶数一旦确定，尽量不要改。如果非要改，建议重新开实验，不要复用旧数据。

3. 坑三：user_id 为空或异常

   匿名用户的 user_id 可能是空字符串或者 null。如果不做处理，哈希函数会报错，或者所有匿名用户都分到同一个桶。

   建议：在分桶前加一层兜底逻辑——如果 user_id 为空，用设备ID或随机 UUID 替代。

3.6 哈希分桶的完整流程

我画了一张流程图，帮你把整个链路串起来：

3.7 什么时候该放弃哈希分桶？

最后说点实在的。哈希分桶虽然简单，但有些场景真的不适合：

• 流量需要动态调整：比如你想把实验流量从 5% 慢慢涨到 50%。哈希分桶做不到，你得用分层分桶或者自适应分桶。
• 用户量极少：比如只有几百个用户。哈希分桶的均匀性在大数定律下才成立，用户少的时候偏差会很大。
• 需要跨实验分析：如果多个实验共享同一批用户，哈希分桶容易产生“实验污染”——用户同时参与多个实验，效果互相干扰。

嗯，这些场景我们后面几章会逐一展开。哈希分桶作为基础方案，你先把它的实现和坑摸透，后面学其他方案会轻松很多。