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

背景

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

业务难题

如上图所示是模拟客户的业务网页构建的一个并发访问模型。用户在页面点击从而产生一个 HTTP 请求，这个请求发送到业务生产进程，就会启动一个投递线程（Deliver Thread）调用 Kafka 的 SDK 接口，并发送 3 条消息到 DMS（分布式消息服务），每条消息大小 3k，需要等待 3 条消息都被处理完成后才会返回请求响应⑧。当消息达到 DMS 后，业务消费进程调用 Kafka 的消费接口把消息取出来，然后将每条消息放到一个响应线程(Response Thread)中进行处理，响应线程处理完后，通过 HTTP 请求通知投递线程，投递线程收到响应后返回回复响应。

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 队列时延表现差的问题怎么解决？

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

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

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

入队时延

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

发送时延

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

写入时延

消息写入到 Kafka Leader 的时间。

复制时延

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

拉取时延

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

入队时延

现网是哪一部分的时延最大呢？通过我们的程序可以看到，入队列等待发送时延非常大，如下图：

即消息都等待在生产端的队列中，来不及发送！

我们再看其他时延分析，因为无法在现网测试，我们分别在类生产测试了相同压力的，测试其他各种时延如下↓

复制时延

以下是类生产环境测试的 1 并发下的

从日志上看，复制时延包括在 remoteTime 里面，当然这个时间也会包括生产者写入时延比较慢导致的，但是也从一定的程度反映复制时延也是提升性能时延的一个因素。

写入时延

因为用户使用的是高吞吐队列，写入都是异步落盘，我们从日志看到写入时延非常低，可以判断不是瓶颈。发送时延与拉取时延都是跟网络传输有关系，这个优化主要是通过调 TCP 的参数来决定的。具体的参数调优方法，请期待 Kafka 实战：如何把 Kafka 消息时延秒降 10 倍（下），小哥将为你详细讲解！想要轻松将 Kafka 消息时延秒降 10 倍，就用华为云 DMS！

本文转载自公众号中间件小哥（ID：huawei_kevin）。

原文链接：

https://mp.weixin.qq.com/s/fLN-ww9A7lN8qhb0lYdDqQ