超1.5万台Kafka，每秒数亿消息量的挑战

Kafka在美团数据平台承担着统一的数据缓存和分发的角色，随着数据量的增长，集群规模的扩大，Kafka面临的挑战也愈发严峻。本文分享了美团Kafka面临的实际挑战，以及美团针对性的一些优化工作，希望能给从事相关开发工作的同学带来帮助或启发。

一、现状和挑战

1.1 现状

1.2 挑战

二、读写延迟优化

2.1 概览

2.2 应用层

2.3 系统层

2.4 混合层-SSD新缓存架构

三、大规模集群管理优化

3.1 隔离策略

3.2 全链路监控

3.3 服务生命周期管理

3.4 TOR容灾

四、未来展望

一、现状和挑战

1、现状

Kafka是一个开源的流处理平台，我们首先了解一下Kafka在美团数据平台的现状。

图1-1 Kafka在美团数据平台的现状

如图1-1所示，蓝色部分描述了Kafka在数据平台定位为流存储层。主要的职责是做数据的缓存和分发，它会将收集到的日志分发到不同的数据系统里，这些日志来源于系统日志、客户端日志以及业务数据库。下游的数据消费系统包括通过ODS入仓提供离线计算使用、直接供实时计算使用、通过DataLink同步到日志中心，以及做OLAP分析使用。

Kafka在美团的集群规模总体机器数已经超过了15000+台，单集群的最大机器数也已经到了2000+台。在数据规模上，天级消息量已经超过了30+P，天级消息量峰值也达到了4+亿/秒。不过随着集群规模的增大，数据量的增长，Kafka面临的挑战也愈发严峻，下面讲一下具体的挑战都有哪些。

2、挑战

图1-2 Kafka在美团数据平台面临的挑战

如图1-2所示，具体的挑战可以概括为两部分：

1）慢节点影响读写，这里慢节点参考了HDFS的一个概念，具体定义指的是读写延迟TP99大于300ms的Broker。造成慢节点的原因有三个：

• 集群负载不均衡会导致局部热点，就是整个集群的磁盘空间很充裕或者ioutil很低，但部分磁盘即将写满或者ioutil打满。

• PageCache容量，比如说，80GB的PageCache在170MB/s的写入量下仅能缓存8分钟的数据量。那么如果消费的数据是8分钟前的数据，就有可能触发慢速的磁盘访问。

• Consumer客户端的线程模型缺陷会导致端到端延时指标失真。例如当Consumer消费的多个分区处于同一Broker时，TP90可能小于100ms，但是当多个分区处于不同Broker时，TP90可能会大于1000ms。

2）大规模集群管理的复杂性，具体表现有4类问题：

• 不同Topic之间会相互影响，个别Topic的流量突增，或者个别消费者的回溯读会影响整体集群的稳定性。

• Kafka原生的Broker粒度指标不够健全，导致问题定位和根因分析困难。

• 故障感知不及时，处理成本较高。

• Rack级别的故障会造成部分分区不可用。

二、读写延迟优化

接下来我们先介绍一下针对读写延迟问题，美团数据平台做了哪些优化。首先从宏观层面，我们将受影响因素分为应用层和系统层，然后详细介绍应用层和系统层存在的问题，并给出对应的解决方案，包括流水线加速、Fetcher隔离、迁移取消和Cgroup资源隔离等，下面具体介绍各种优化方案的实现。

1、概览

图2-1 Kafka读写延迟优化概览

图2-1是针对读写延迟碰到的问题以及对应优化方案的概览图。我们把受影响的因素分为应用层和系统层。

应用层主要包括3类问题：

1）Broker端负载不均衡，例如磁盘使用率不均衡、ioutil不均衡等问题。个别磁盘负载升高影响整个Broker的请求受到影响。

2）Broker的数据迁移存在效率问题和资源竞争问题。具体来讲，包括以下3个层面：

• 迁移只能按批次串行提交，每个批次可能存在少量分区迁移缓慢，无法提交下个批次，导致迁移效率受影响。

• 迁移一般在夜间执行，如果迁移拖到了午高峰还未完成，可能会显著影响读写请求。

• 迁移请求和实时拉取存在共用Fetcher线程的问题导致分区迁移请求可能会影响实时消费请求。

3）Consumer端单线程模型存在缺陷导致运维指标失真，并且单Consumer消费的分区数不受限制，消费能力不足就无法跟上实时最新的数据，当消费的分区数增多时可能会引起回溯读。

系统层也主要包括3类问题：

1）PageCache污染。Kafka利用内核层提供的ZeroCopy技术提升性能，但是内核层无法区分实时读写请求和回溯读请求，导致磁盘读可能污染PageCache，影响实时读写。

2）HDD在随机读写负载下性能差。HDD对于顺序读写友好，但是面对混合负载场景下的随机读写