峰值超2亿/秒，Kafka在美团数据平台的逆袭之战

本文将介绍Kafka在美团数据平台的实践，主要内容包括：

• Kafka在美团数据平台的发展现状和面临的挑战，主要是海量数据下如何保证读写延迟的问题，以及大规模的集群管理与优化；
• 面对上述挑战，美团所做的优化实践；
• 未来美团数据平台Kafka的优化方向。

一、现状和挑战

1、现状

首先了解一下Kafka在美团数据平台的现状。

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

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

Kafka在美团的集群规模总体机器数已经超过了7500台，单集群的最大机器数也已经到了1500台。数据规模上，天级消息量已经超过了21P，天级的消息条数达到了11.3万亿，天级消息量峰值也达到了2.46亿/秒。

随着集群规模的增大，数据量的增长，Kafka面临的挑战也是愈发的严峻。下面看一下具体的挑战有哪些。

2、挑战

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

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

第一部分是慢节点影响读写，这里慢节点参考了HDFS的一个概念，具体定义指的是读写延迟tp99大于300ms的broker。影响慢节点的原因有三个，第一个是集群负载不均衡会导致局部热点，就是整个集群的磁盘空间很充裕或者ioutil很低，但部分磁盘即将写满或者ioutil打满；第二个是pagecache容量不足会导致磁盘IO瓶颈。比如说，80GB的pagecache在170MB/s的写入量下仅能缓存8分钟的数据量。那么如果消费的数据是8分钟前的数据，就有可能触发磁盘读；第三个是consumer线程模型缺陷会导致延时指标的失真。例如当消费的分区处于同一broker时，tp90可能小于100ms，但是当他们处于不同broker时，tp90可能会大于100ms。

第二部分是大规模集群运维的复杂性，具体表现有四个方面，一是不同topic之间会相互影响，某些或某个topic的流量突增，或者某些消费者的回溯读会影响整体集群的稳定性；二是Kafka原生的broker粒度的指标不够健全，问题的根因分析变得很困难；三是故障的感知无法做到及时，故障处理成本很高；四是Rack级别的故障会造成部分分区不可用。

二、读写延迟优化

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

1、概览

图2-1 Kafka概览图

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

应用层，主要表现在系统设计的不合理导致，包括消费者端的单线程模型存在缺陷导致运维指标失真，并且单consumer消费的分区数是不受限制的，当消费的分区数增多的时候可能会引起回溯读，因为消费能力不足就无法跟上实时最新的数据；其次是broker端，broker端主要表现在负载不均衡上，具体表现是磁盘使用率不均衡方面。

我们针对此做了磁盘均衡，但磁盘均衡需要使用分区迁移，分区迁移又引入了一些新的问题，包括迁移只能按批提交，这存在长尾问题，以及迁移fetcher和实时拉取fetcher存在资源竞争，分区迁移的fetcher会影响实时消费。

系统层，主要包括三个方面，一是pagecache的容量不足会导致磁盘读写，磁盘读写的性能显著慢于内存，而且容量不足时还会导致pagecache污染，pagecache污染后，磁盘读和回溯读会影响实时读；另一方面，Kafka目前使用的disk主要是HDD，HDD是比较符合顺序读写的场景。但是对于随机读写的场景，它的性能是不足的；最后由于CPU的资源竞争，在美团这边为了提高资源的利用率，IO密集型的服务（比如Kafka）会和CPU密集型的服务（比如实时作业）混布，混布其实是存在资源竞争的，也会影响读写的延迟。

针对刚才提到的应用层和系统层存在的各种问题，我们这边分层的去解决。对于应用层提到的每一点问题都会有针对性的解决方案，比如说限流、流水线加速、资源隔离等。针对系统层存在的问题，我们做了cgroup的优化以及物理核的隔离来保证当CPU实时计算的飙升时不会影响读写延迟。

2、应用层

1）磁盘均衡