1. 项目背景与核心挑战
去年参与外卖平台骑手调度系统升级时，我们遇到了一个看似简单但极具挑战性的需求——实时展示全国百万骑手的综合绩效排行榜。这个功能不仅要满足运营人员监控全局的需求，还要作为骑手端APP的核心激励模块。当时系统日均订单量已突破3000万，骑手在线峰值超过120万，传统基于数据库的方案完全无法支撑。
核心痛点集中在三个方面：
- 数据规模：单日骑手行为事件超过20亿条
- 实时性要求：排行榜数据延迟必须控制在3秒内
- 计算复杂度：涉及准时率、接单量、服务分等7个维度的加权计算
2. 技术架构设计
2.1 整体架构选型
我们最终采用的方案是流批一体的Lambda架构，核心组件如下：
[客户端] → [Kafka] → [Flink实时计算] → [Redis集群] ↘ [Hive离线计算] ↗关键设计决策：
选择Redis而非ES的原因：
- ZSET天然支持排行榜功能
- 单机10W+ QPS的写入性能
- 原生支持CAS原子操作
采用双链路计算的考虑：
- 实时链路处理核心指标（接单量、准时率）
- 离线链路每天凌晨重算历史数据（投诉率等长周期指标）
2.2 数据模型设计
骑手得分采用复合权重算法：
def calculate_score(orders, on_time_rate, complaints): base = min(orders, 50) * 2 # 接单量基础分 bonus = max(0, orders - 50) * 1.5 # 超额奖励 quality = on_time_rate * 100 * 0.7 # 质量分 penalty = complaints * 10 # 投诉扣分 return base + bonus + quality - penalty存储结构示例：
ZADD rider_rank 1528.3 rider:10086 ZADD rider_rank 1892.1 rider:100103. 核心实现细节
3.1 实时计算管道
Flink作业关键配置：
env.enableCheckpointing(5000); // 5秒checkpoint env.setParallelism(32); // 按城市分片处理处理流程：
- 消费Kafka中的订单完成事件
- 按骑手ID进行KeyBy分组
- 滑动窗口(5分钟)聚合基础指标
- 通过RedisSink实时更新排行榜
重要提示：必须设置合理的State TTL，我们遇到过状态数据膨胀导致作业崩溃的问题
3.2 冷热数据分离
采用分层存储策略：
- 热数据（Top 10万）：全内存存储
- 温数据（10-50万）：Redis + 持久化
- 冷数据（50万+）：每日同步到MySQL归档
内存优化技巧：
- 骑手ID采用前缀压缩（如"rider:"→"r:"）
- 分数存储使用double而非字符串
- 启用Redis的ziplist编码优化
4. 性能优化实战
4.1 读写分离方案
搭建Redis Cluster集群：
- 6个主节点（16核64G）
- 12个从节点（8核32G）
- 代理层使用Twemproxy做分片
压测数据：
| 场景 | QPS | 平均延迟 |
|---|---|---|
| 纯写入 | 28万 | 8ms |
| 纯读取 | 65万 | 3ms |
| 混合负载 | 42万 | 15ms |
4.2 防雪崩设计
多级缓存策略：
- 本地缓存（Caffeine）：存储Top100数据
- 分布式缓存（Redis）：全量数据
- 持久层（MySQL）：历史数据
降级方案：
- 实时数据异常时自动切换离线快照
- 极端情况下返回静态Top100榜单
5. 踩坑记录与解决方案
典型问题1：ZSET内存暴增
- 现象：单个ZSET超过500万成员时，内存占用突破32G
- 根因：Redis默认使用skiplist编码
- 解决：调整zset-max-ziplist-entries参数为10000
典型问题2：热点骑手问题
- 现象：头部骑手数据频繁变更导致CPU飙升
- 优化：对Top100骑手采用单独分片
- 效果：写性能提升40%
典型问题3：跨地域延迟
- 挑战：骑手分布在全国200+城市
- 方案：搭建三大区域中心（华北、华东、华南）
- 同步：通过Redis GEO命令实现就近访问
6. 扩展思考
这套架构后来被复用到其他场景：
- 商家热榜：基于订单量、评分的动态排名
- 菜品推荐：结合实时销量的智能排序
- 运力调度：根据骑手位置和负载的智能匹配
实际运营中发现，排行榜的更新频率需要动态调整：
- 高峰时段：每分钟更新
- 平峰时段：每5分钟更新
- 夜间时段：每小时更新
这种弹性更新策略使得集群资源消耗降低了35%，而用户体验几乎没有感知差异。最近我们正在尝试用时间序列数据库替代部分Redis功能，以支持更复杂的历史趋势分析。
