桶排序在大促积分场景中用于构建可伸缩低延迟的分拣与排名体系，核心是分而治之、范围映射与局部处理，而非直接排序。
桶排序在高并发大促积分场景中不是直接拿来排序，而是借其“分而治之+范围映射+局部处理”的模式，构建可伸缩、低延迟的积分分拣与排名体系。核心不在排序本身，而在用桶思想解耦数据分布、降低单点压力、支持并行响应。
一、为什么桶排序模式比直接排序更适配大促积分场景
大促期间积分更新高频（如每秒数万次）、查询密集（Top100、个人实时名次）、数据天然具备范围聚集性（95%用户积分集中在0–5000分），但传统全量ZSet或数据库ORDER BY会迅速成为瓶颈。桶排序模式的价值在于：
- 把全局有序问题，转化为“桶内局部有序 + 桶间顺序管理”的两级结构，避免单一大Key和全量扫描
- 桶按积分区间静态划分（如每100分一个桶），映射关系确定、无哈希冲突，查询O(1)定位桶
- 每个桶内数据量可控（平均数百人），插入/计数/范围查询均在毫秒级完成
- 天然支持水平扩展：桶可分散到不同Redis分片，或落地为独立小表
二、实战分桶架构设计（以千万级用户为例）
不依赖单一ZSet，而是组合三个轻量级Redis结构，复用桶排序的分配逻辑：
- user:score（Hash）：存 uid → score 映射，用于快速查用户当前积分（O(1)）
- rank:bucket:{base}（ZSet）：每个桶是一个ZSet，key为起始分（如rank:bucket:2000），member是uid，score是真实积分；仅存该区间[2000, 2099]内用户
- bucket:count（Hash）：记录各桶人数，如 HSET bucket:count 2000 342，便于快速累加前序桶总人数
桶粒度建议：50–200分/桶。太细（如1分/桶）导致桶数爆炸（上万桶），管理开销大；太粗（如1000分/桶）则单桶膨胀，失去分治意义。实测100分/桶在千万用户下约5万个桶，平衡性最佳。
三、关键操作如何用桶模式高效实现
所有操作围绕“定位桶→操作桶→聚合结果”三步展开，全程在Lua脚本中原子执行：
- 查个人实时排名：先查 user:score 得积分 s；算桶ID = (s / 100) * 100；用 ZCOUNT rank:bucket:{id} (s +inf 统计桶内更高分人数；再用 ZRANGEBYSCORE bucket:index -inf {id-1} 获取所有更高桶ID，HGETALL 累加 bucket:count；最终排名 = 前序桶总人数 + 桶内更高分人数 + 1
- 更新积分（如+85分）：从原桶移除uid，加入新桶；同步增减两个桶的 bucket:count；更新 user:score。整个过程一次Lua调用完成，无竞态
- 查TopN（如Top100）：从最高桶开始逐桶 ZREVRANGE，累计够N个即停；若某桶不足，继续取下一桶。因高分用户集中在少数顶部桶，通常3–5次ZSet查询即可返回
四、应对数据倾斜与长尾用户的优化技巧
实际中存在少量超高分用户（如运营刷榜、头部KOL），可能使顶部桶严重膨胀。此时需动态干预：
- 对积分 > 10000 的用户启用“子桶”：将[10000, ∞)再按1000分切二级桶（如rank:bucket:super:10000、rank:bucket:super:11000），避免单桶过大
- 冷热分离：高频访问的Top10000分区间用内存ZSet；低频长尾区间（如0–100分）可降级为MySQL分表+定时汇总，节省Redis资源
- 桶自动合并/分裂：监控各桶 size，当某桶持续 > 2000人且增长快时，触发后台任务将其等分拆为两个新桶，并迁移数据（异步执行，不影响线上）
不复杂但容易忽略：桶边界必须左闭右开（如[1000,1099]），避免同分用户被分到不同桶；所有桶ID统一用整数起始值（非字符串），保障ZSet范围查询和Hash键名一致性。
