王萌萌, 美团 作为美团大数据平台的基础设施之一，Kafka支撑了美团内部众多业务线在数据采集、实时数仓、实时事件处理等方面的应用。本次分享主要介绍Kafka在美团的应用情况，以及我们在性能、稳定性、平台化管理方面的一些实践与优化经验。 https://www.meetup.com/Beijing-Kafka-Meetup/events/281812695/

1. 美团数据平台之Kafka应用实践和优化
美团数据平台中心
王萌萌
美团数据平台中心-数据集成团队负责人

2. 个人简介
王萌萌，美团大数据平台数据集成方向负责人，
2015年加入美团，主要负责为美团大数据生产分
析提供数据采集、集成、分发服务。在海量数据
采集、异构数据源数据同步、消息队列等方面有
较多的实践经验。

3. 大纲
• 背景介绍
• 实践1：读写延时优化
• 实践2：元数据服务稳定性提升
• 实践3：平台化管理
• 后续规划

4. 背景介绍-Kafka在美团大数据体系的应用
• 业务定位：
Ø 数据采集管道
Ø 实时数据分发
• 典型服务场景：
Ø 离线计算的缓存层
Ø 实时数仓
Ø 实时事件处理

5. • 集群规模：
Ø 物理集群：30+
Ø 逻辑集群：100+
Ø 单集群最大broker数： 1800+
• Topic规模：
Ø topic总数：10w+
Ø 单集群最大partition数：10w+
• 数据规模：
Ø 峰值吞吐：700TB/s，3亿+ msg/s
Ø 天级消息量：23w亿+
背景介绍-服务规模

6. • SSD缓存架构
• 均衡策略
• 请求队列拆分
• sticky分区策略
实践1-读写延时优化

7. • 业务背景：延迟消费&实时消费场景并存
• 线上问题： PageCache容量不足引起磁盘读，不
仅速度变慢，而且会污染PageCache，影响其他
读写请求
累计百分比
请求时间分布
读写延时优化-SSD缓存架构

8. • 权衡成本与性能，引入SSD作为PageCache和HDD间的缓存层
• 热数据读SSD，冷数据读HDD
读写延时优化-SSD缓存架构

9. • 效果（延迟读较严重的集群）：
Ø TP99 写入时间从40ms+降至5ms
Ø TP99 读取时间从300ms+降至180ms+
Ø HDD磁盘读取占比从19.5%降至1%
读写延时优化-SSD缓存架构

10. • 背景：
Ø 机型异构，磁盘容量各异
Ø 业务多样，流量差异大
• 问题：
Ø 磁盘利用率不均衡，偶发打满
Ø broker处理能力不均衡，热点频发
• 解法：
Ø 事前：空闲磁盘优先的副本分配算法
Ø 事后：流量、磁盘容量多维度均衡
读写延时优化-均衡策略

11. • RoundRobin分配算法未考虑磁盘使用情况
• 改进：副本分配时采用空闲磁盘优先（IDF）策略。IDF基于箱子模型实现，每块磁盘被划分
为若干块大小相等的箱子（30GB），每个分区占用1~n个箱子
均衡策略-空闲磁盘优先的副本分配算法

12. • 迁移算法：
Ø 整体策略：使用率高的磁盘迁移至使用率低的磁盘
Ø 细节策略：
ü 考虑多磁盘规格，不同容量磁盘权重不同
Ø 限制条件：
ü 保证replica分布在不同的broker上
ü 保证partition在不同磁盘上的数量均匀
ü 保证TOR容灾
ü 尽量保证partition/leader数均衡
均衡策略-磁盘均衡

13. 均衡策略-磁盘均衡效果

14. • 挑战：迁移效率 vs 读写稳定性
• 优化方案：
Ø 提升迁移效率：
ü 流水线加速，长尾分区不影响整体迁移速度
Ø 提升迁移稳定性：
ü 低峰期迁移
ü 迁移并发控制、迁移限速
ü fetcher隔离
数据迁移优化

15. • 按批次（逻辑集群）提交迁移计划，串行执行 =>满足限流条件下，流水线向zk补充提交reassign
数据迁移优化-流水线加速

16. • 背景：follower实时读和延迟读共享一个fetcher线程，
延迟读影响实时读
Ø 延迟读的请求量远大于实时读，导致实时读请求积压
Ø 延迟读触发读磁盘，显著拖慢fetcher的拉取效率
• 改进：
Ø 所有ISR的follower共享fetcher
Ø 所有非ISR的follower共享fetcher
数据迁移优化-fetcher隔离

17. • 评价指标：同集群内leader写入速率的方
差尽可能小
• 细节设计：
Ø reassign和prefer提交流水线化
Ø region粒度的管理能力
Ø 关键参数配置化：
ü 执行时间
ü leader切换并发
ü reassign并发
均衡策略-流量均衡

18. • 核心组件处理链路分析：
Ø Processor
Ø RequestHandler
读写延时优化-请求队列拆分&sticky分区策略

19. • Processor瓶颈分析：
Ø 对线上的慢节点，io-ratio和io-wait-ratio均很低->瓶颈在process
读写延时优化-请求队列拆分&sticky分区策略

20. • Processor的瓶颈：
高QPS的produce请求->
processor处理性能下降->
responseQueueTime升高，
responseTime升高
->totalTime升高
读写延时优化-请求队列拆分&sticky分区策略

21. • RequestHandler分析：
Ø 多线程阻塞模型，多个RequestHandler共同消费
RequestQueue
Ø 可能的瓶颈点：mmap触发磁盘读写，降低
RequestQueue消费速度，反压引起Processor阻
塞
读写延时优化-请求队列拆分&sticky分区策略

22. • 线上真实情况：
Ø 高produce QPS造成 requestQueue拥堵（80%+）
• 指标体现：network handler idle percent <= 0.2 && request handler idle percent >0.2
Ø requestHandler处理慢，反压到processor（10%+）
• 指标体现：request handler idle percent <= 0.2
读写延时优化-请求队列拆分&sticky分区策略

23. • 解法：
Ø 读写请求队列拆分，避免写影响读
Ø 客户端sticky方式发送，降低QPS
• 业务背景：
Ø 超过一半的写请求来自日志收集，客户端可控
读写延时优化-请求队列拆分&sticky分区策略

24. • 效果：
Ø 客户端sticky策略：QPS降低为原来的1/20，吞吐&延时变化不大
Ø 读写队列拆分：
ü 集群1（高QPS）：读延迟下降80%，QPS增加40%
ü 集群2（非高QPS）：读写QPS/延迟无显著变化， ProcessorIdlePercent提升， QueueTime耗
时降低70%
读写延时优化-请求队列拆分&sticky分区策略

25. • 背景：
Ø 集群规模过大，节点变更（掉线、升级等）频繁，元数据广播压力大（broker数*partition数）
Ø FullGC频繁，主备controller切换，影响客户端消费
• 针对不同场景分别处理：
Ø broker状态变更：broker startup/failure，此时的广播不必须
Ø controllor failover：需要全量广播，分批进行
实践2：元数据服务稳定性提升-广播优化

26. • 背景：依赖zk做节点探活，当zk故障恢复后controller产生误判，进行不必要的meta更新，误
判分区不可用，从而影响客户端消费
元数据服务稳定性提升-SafeMode

27. • SafeMode：对掉线节点数量进行判断，超过阈值即进入SafeMode状态
元数据服务稳定性提升- SafeMode

28. • 核心指标监控
Ø 服务端指标：基础环境指标（IO/Mem/CPU）、分阶段请求延迟、入出流量
Ø 客户端视角的指标：请求延迟分布、元数据接口成功率
Ø partition/broker/集群多维度聚合统计
实践3-平台化管理

29. • 核心指标监控
• 自动化运维：机器管理、扩容升级、数据迁移、数据均衡
实践3-平台化管理

30. • 能力扩展：
Ø 事务能力
• 稳定性：
Ø 硬件故障容错
Ø QoS能力
• 扩展性：
Ø 存算分离
Ø 弹性架构
后续规划

31. Q&A

32. 邮箱：jinlai_ch@qq.com