一次性完整剖析Kafka数据端到端延迟的详解总结

用户9421738

发布于 2024-07-02 11:14:24

1350

发布于 2024-07-02 11:14:24

文章被收录于专栏：大数据从业者

前言

在线业务诸如欺诈检测、支付系统和股票交易平台等场景，要求Kafka数据高效可靠地传输。本文详细剖析Kafka数据传输端到端延迟的内容、在保证延迟指标的同时，通过配置和扩展业务程序获得更高吞吐量。

端到端延迟详解

简单概述地说，端到端延迟就是从业务程序KafkaProducer.send()开始发送消息到业务程序KafkaConsumer.poll()读取到消息的耗时。如图描述详细的端到端延迟构成：

Produce time：Kafka producer批量缓存消息的耗时
Publish time：Kafka producer发送消息到leader的耗时
Commit time：follower从leader复制消息的耗时
Catch-up time：kafka consumer顺序消费追赶到消息的耗时
Fetch time：Kafka consumer读取到消息的耗时

业务程序使用Kafka客户端的方法及具体配置通常影响端到端，了解每个阶段的耗时情况很有必要。本文后续详细解释每个阶段耗时的具体情况。

Produce time详解

定义：业务程序通过KafkaProducer.send()生产消息到携带该消息的请求开始发送到该消息所属partition leader节点的总耗时。具体包括如下：

1. 攒批耗时：考虑到网络和IO性能优化，producer将属于相同partition的消息攒批缓存之后再批量发送到Kafka。通过调整linger.ms和batch.size参数，可以控制批量发送时间和批大小。

2. 压缩耗时：如果producer设置压缩参数，根据实际压缩算法，批量消息会以不同压缩比进行压缩后再发送到Kafka。

3. 请求等待耗时：打满Broker max.inflight.requests.per.connection阈值，producer请求会有等待耗时。

Publish time详解

定义：从携带消息的producer请求开始发送到leader将消息写入Log的时间。network线程从TCP连接中拿producer请求将其放入到请求队列，handler线程从请求队列拿producer请求进行处理。具体包括如下：

1. 网络耗时：producer请求网络传输的时间

2. 排队耗时：producer请求在请求队列中等待的时间

3. 处理耗时：将producer请求中的消息写log的时间(系统内存充足，就是写page cache的时间)。当broker负载较轻时，网络耗时和处理耗时对publish time影响更大；当broker负载较重时，排队耗时对push time影响更大。

Commit time详解

定义：所有in-sync副本之间同步消息的耗时。Kafka暴露给consumer的消息都是commited之后的，换句话说，只有消息被commited了，consumer才可见、才能消费。所谓的commited就是消息被所有in-sync副本都复制，达到容错的目的。所有followers并行从leader拉取消息，Commit time就是拉取最慢的那个follower的耗时。

Catch-up time详解

定义：除了指定offset消费或者新consumer消费的情况，单分区内consumer都是顺序消费消息。如果consumer性能比较差，就会出现消息已经被commited，比如offset=N，但是consumer才消费到小于N的某个offset。Catch-up time说的就是consumer消费到最新消息的耗时。

对于实时业务场景，最好的情况肯定是Catch-up time=0，也就是一旦消息被commited，consumer就能立即消费到。如果consumer一直追不上最新的消息，Catch-up time可能会越来越大。总结：catch-up time取决于consumer吞吐能否赶上produce吞吐。