Kafka客户端会话机制及Keycloak频繁认证请求咨询

一、Kafka客户端的会话处理逻辑 #

Kafka客户端与Broker的底层通信依赖TCP长连接，在此基础上叠加了Kafka自身的连接管理逻辑：

• 客户端初始化后，会先与目标Broker建立TCP连接，紧接着完成SASL认证（你这里采用Plain机制，通过自定义listener.name.sasl_plaintext.plain.sasl.server.callback.handler.class委托Keycloak做身份校验）。
• 认证通过后，该TCP连接会被复用，用于发送后续的生产请求、元数据请求等，不会每次请求都重新建立连接。
• Kafka没有单独的“应用层会话”概念，SASL认证的有效性绑定在TCP连接的生命周期内——只要连接未断开，后续请求无需重新认证。

二、间隔不到1分钟触发频繁认证请求的可能原因 #

结合你的配置和现象，以下是核心排查方向：

• 中间网络设备的空闲连接超时：防火墙、负载均衡器这类设备通常默认设置1分钟左右的空闲连接超时，如果客户端与Broker的TCP连接在这段时间内无数据传输，会被主动断开。客户端检测到连接中断后，会立即重建连接并触发SASL认证，导致Keycloak收到重复请求。
• Broker端的空闲连接回收配置：检查Broker的connections.max.idle.ms参数，若该值被设置为小于1分钟（比如30000ms），Broker会主动掐断空闲连接，客户端不得不重新连接并认证。
• 自定义Callback Handler未做缓存：你的com.xxxxxx回调处理器如果每次认证都直接调用Keycloak校验，未在Broker端做本地缓存（比如缓存已通过校验的用户/凭证一段时间），那么每次重新连接都会触发一次Keycloak请求，连接频繁断开则请求量激增。
• 客户端连接异常或重试逻辑触发：若生产请求频繁失败（比如Broker过载、网络抖动），客户端的重试机制可能会触发连接重建；另外，若客户端connection.timeout.ms设置过小，也可能导致连接被频繁断开重建。
• 多生产者实例/线程的连接竞争：如果部署了多个Spring Kafka生产者实例，或同一实例内多线程并发生产，可能会创建多个TCP连接到Broker，每个连接都需要单独完成SASL认证，进而增加Keycloak的请求量。

内容的提问来源于stack exchange，提问作者Said