-
1. 现状和挑战
-
1.1 现状
-
1.2 挑战
-
-
2. 读写延迟优化
-
2.1 概览
-
2.2 应用层
-
2.3 系统层
-
2.4 混合层-SSD新缓存架构
-
-
3. 大规模集群管理优化
-
3.1 隔离策略
-
3.2 全链路监控
-
3.3 服务生命周期管理
-
3.4 TOR容灾
-
-
4 未来展望
1. 现状和挑战
1.1 现状
Kafka是一个开源的流处理平台,我们首先了解一下Kafka在美团数据平台的现状。
如图1-1所示,蓝色部分描述了Kafka在数据平台定位为流存储层。主要的职责是做数据的缓存和分发,它会将收集到的日志分发到不同的数据系统里,这些日志来源于系统日志、客户端日志以及业务数据库。下游的数据消费系统包括通过ODS入仓提供离线计算使用、直接供实时计算使用、通过DataLink同步到日志中心,以及做OLAP分析使用。
Kafka在美团的集群规模总体机器数已经超过了15000+台,单集群的最大机器数也已经到了2000+台。在数据规模上,天级消息量已经超过了30+P,天级消息量峰值也达到了4+亿/秒。不过随着集群规模的增大,数据量的增长,Kafka面临的挑战也愈发严峻,下面讲一下具体的挑战都有哪些。
1.2 挑战
如图1-2所示,具体的挑战可以概括为两部分:
第一部分是慢节点影响读写,这里慢节点参考了HDFS的一个概念,具体定义指的是读写延迟TP99大于300ms的Broker。造成慢节点的原因有三个:
-
集群负载不均衡会导致局部热点,就是整个集群的磁盘空间很充裕或者ioutil很低,但部分磁盘即将写满或者ioutil打满。
-
PageCache容量,比如说,80GB的PageCache在170MB/s的写入量下仅能缓存8分钟的数据量。那么如果消费的数据是8分钟前的数据,就有可能触发慢速的磁盘访问。
-
Consumer客户端的线程模型缺陷会导致端到端延时指标失真。例如当Consumer消费的多个分区处于同一Broker时,TP90可能小于100ms,但是当多个分区处于不同Broker时,TP90可能会大于1000ms。
第二部分是大规模集群管理的复杂性,具体表现有4类问题:
-
不同Topic之间会相互影响,个别Topic的流量突增,或者个别消费者的回溯读会影响整体集群的稳定性。
-
Kafka原生的Broker粒度指标不够健全,导致问题定位和根因分析困难。
-
故障感知不及时,处理成本较高。
-
Rack级别的故障会造成部分分区不可用。
2. 读写延迟优化
接下来我们先介绍一下针对读写延迟问题,美团数据平台做了哪些优化。首先从宏观层面,我们将受影响因素分为应用层和系统层,然后详细介绍应用层和系统层存在的问题,并给出对应的解决方案,包括流水线加速、Fetcher隔离、迁移取消和Cgroup资源隔离等,下面具体介绍各种优化方案的实现。
2.1 概览
图2-1是针对读写延迟碰到的问题以及对应优化方案的概览图。我们把受影响的因素分为应用层和系统层。
应用层主要包括3类问题:
1)Broker端负载不均衡,例如磁盘使用率不均衡、ioutil不均衡等问题。个别磁盘负载升高影响整个Broker的请求受到影响。
2)Broker的数据迁移存在效率问题和资源竞争问题。具体来讲,包括以下3个层面:
-
迁移只能按批次串行提交,每个批次可能存在少量分区迁移缓慢,无法提交下个批次,导致迁移效率受影响。
-
迁移一般在夜间执行,如果迁移拖到了午高峰还未完成,可能会显著影响读写请求。
-
迁移请求和实时拉取存在共用Fetcher线程的问题导致分区迁移请求可能会影响实时消费请求。
3)Consumer端单线程模型存在缺陷导致运维指标失真,并且单Consumer消费的分区数不受限制,消费能力不足就无法跟上实时最新的数据,当消费的分区数增多时可能会引起回溯读。
系统层也主要包括3类问题:
1)PageCache污染。Kafka利用内核层提供的ZeroCopy技术提升性能,但是内核层无法区分实时读写请求和回溯读请求,导致磁盘读可能污染PageCache,影响实时读写。
2)HDD在随机读写负载下性能差。HDD对于顺序读写友好,但是面对混合负载场景下的随机读写,性能显著下降。
3)CPU和内存等系统资源在混部场景下的资源竞争问题。在美团大数据平台,为了提高资源的利用率,IO密集型的服务(