Spring Kafka中通过参数配置解决超时问题

背景

这是我们团队负责的一个不太核心的服务。之前与外部交互时应外部要求由普通kafka集群改成加密kafka集群。我们是数据生产端。

改的过程中并跑上线，60%的请求耗时增加了2倍，也还是在百毫秒的量级可以接受。但是每次重启的第一个请求要5s以上，会超过；运行过程中，一两个月也会有一次超时。因为我们有三次重试，整体没有影响成功率。

上线的时候我们问过网络组，还专门请教过公司专业负责kafka的团队。结论是：第一，这个慢是外部交互方的问题，不是咱们这边可以处理的；第二，参数上也没有什么可以调优的。

我们团队内部还是不信邪，调了几个参数，加测之后上线了。频繁度降到了现在的一两个月一次超时，但是没有根治。因为本身这个服务不是特别核心，本身外部是允许有一定失败率的，而且现在实际上也没有失败，几年内业务量也是很平稳的：1分钟4笔。

而我上班时间的状态基本上是我站在两个人中间，我目的是想问一个人问题，结果却先要回答另外一个人的问题，这时候还会出现第四个人说别的事。这个优先级排不上。但是心疼开发小哥哥，每一两个月就要处理一下因为这件事引起的告警。虽然实际不影响，告警出来了，我们就要排查核对是否还是这个问题，并且确实通过重试将消息推送出去了。

所以本次利用周末，希望可以根治这个疑难杂症，减少运维成本。

思路

前期已经明确了这个外部的加密集群建立连接和数据传输速度都慢于之前的普通集群。之所以第一次慢和每一两个月会慢一次都是连接断开重连造成的。之前我们进行过参数调优，调优做的就是因为1分钟4笔请求，线上以最小部署单元3台机器部署，每台机器1分钟预计处理一笔请求。根据这个数据调整了空闲自动断开连接的时间间隔，保证连接不会因为空闲自动断开。线上验证有效，也侧面证实了是连接过程慢引起的超时。

因为建立连接过程慢，这个主要是外部提供的集群就是如此。既然目前并不影响实际发送成功率。人家代表的是大佬，我们也不好太强硬的去推他们解决。所以我的思路有两个：

第一，探索将建立连接与发送数据分离的可行性：程序启动后先将连接建立好再提供服务。如果生产端是这样实现的。那也许还可以进行连接自动探测，如果连接断开则自动重连，不要等发送数据时再发现连接已断开。