http消息无法写入_Kafka实战：如何把Kafka消息时延秒降10倍

最新推荐文章于 2024-08-30 09:51:55 发布

呆呆美要暴富

最新推荐文章于 2024-08-30 09:51:55 发布

阅读量435

点赞数

文章标签： http消息无法写入

本文链接：https://blog.csdn.net/weixin_35792468/article/details/112090655

版权

某大型税务系统在使用DMS Kafka队列时遇到高时延问题，与自建原生Kafka相比，时延高达500ms。通过对并发访问、入队、复制和写入时延的分析，发现了问题所在并提出了解决方案，以降低时延至秒级以下。

摘要由CSDN通过智能技术生成

业务背景

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

业务难题

如上图所示是模拟客户的业务网页构建的一个并发访问模型。用户在页面点击从而产生一个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的并发量，得到如下的时延结果对比表：

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

时延分析

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

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

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

发送时延：消息从生产者发送到服务端的时
写入时延：消息写入到Kafka Leader的时间
复制时延：消费者只可以消费到高水位以下的消息（即被多个副本都保存的消息），所以消息从写入到Kafka Leader，到所有副本都写入该消息直到上涨至高水位这段时间就是消息复制的时延。
拉取时延：消费者采用pull模式拉取数据，拉取过程所用的时间。