Kafka实战：如何把Kafka消息时延秒降10倍

Kafka实战：如何把Kafka消息时延秒降10倍

背景

国内某大型税务系统，业务应用分布式上云改造。

100并发访问时延500ms，未达成用户业务要求

客户提出了明确的要求：每1个两核的ECS要能够支撑并发访问量100，每条消息端到端的时延范围是几十毫秒，即从生产者发送开始到接收到消费者响应的时间。客户实测在使用了DMS的Kafka 队列后，并发访问量为100时时延高达到500ms左右，甚至出现达到秒级的时延，远未达到客户提出的业务诉求。相比较而言，客户在Pod区使用的是自己搭建的原生Kafka，在并发访问量为100时测试到的时延大约只有10~20ms左右。那么问题来了，在并发访问量相同的条件下，DMS的Kafka 队列与Pod区自建的原生Kafka相比为什么时延会有这么大的差异呢？我们DMS的架构师 Mr. Peng对这个时延难题进行了一系列分析后完美解决了这个客户难题，下面就让我们来看看他的心路历程。

难题剖析

根据模拟的客户业务模型，Mr. Peng在华为云类生产环境上也构造了一个测试程序，同样模拟构造了100的并发访问量，通过测试发现，类生产环境上压测得到的时延平均时间在60ms左右。类生产上的时延数值跟客户在真实生产环境上测到的时延差距这么大，这是怎么回事呢？问题变得扑朔迷离起来。

Mr. Peng当机立断，决定就在华为云现网上运行构造的测试程序，来看看到底是什么原因。同时，在客户的ECS服务器上，也部署了相同的测试程序，模拟构建了100的并发量，得到如下的时延结果对比表：

表1 华为云现网与类生产环境时延对比表

从时延对比表的结果看来，Mr. Peng发现，即使在相同的并发压力下，华为云现网的时延比类生产差很多。Mr. Peng意识到，现在有2个问题需要分析：为什么华为云现网的时延会比类生产差？DMS的Kafka队列时延比原生自建的Kafka队列时延表现差的问题怎么解决？Mr. Peng进行了如下分析：

时延分析

回归问题的本质，DMS Kafka队列的时延到底是怎么产生的？可控的端到端时延具体分为哪些？Mr. Peng给出了如下的计算公式：

总时延 = 入队时延 + 发送时延 + 写入时延 + 复制时延 + 拉取时延

让我们来依次了解一下，公式中的每一项都是指什么。

入队时延: 消息进入Kafka sdk后，先进入到要发送分区的队列，完成消息打包后再发送，这一过程所用的时间。

发送时延：消息从生产者发送到服务端的时间。

写入时延：消息写入到Kafka Leader的时间。

复制时延：消费者只可以消费到高水位以下的消息（即被多个副本都保存的消息），所以消息从写入到Kafka Leader，到所有副本都写入该消息直到上涨至高水位这段时间就是消息复制的时延。

拉取时延：消费者采用pull模式拉取数据，拉取过程所用的时间。

（1） 入队时延

即消息都等待在生产端的队列中，来不及发送！我们再看其他时延分析，因为无法在现网测试，我们分别在类生产测试了相同压力的，测试其他各种时延如下：

（3） 写入时延

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。