嘿，这个问题我太熟了！很多人用Kafka批量消费时都会踩这个多分区的坑——毕竟Kafka的消费者天生就是按分区独立管理拉取逻辑的，你遇到的“3个小批次间隔10秒”完全是这个机制导致的。我给你梳理几个可行的方案，不用急着写复杂的自定义实现：

首先，先帮你拆解下当前配置的问题：
你设的fetch-min-size:60_000是单分区的拉取阈值（对应Kafka的fetch.min.bytes），意思是每个分区要凑够60KB才会立即拉取，不然就等10秒（fetch-max-wait）。加上concurrency:1，所有分区都在同一个消费者线程里，但每个分区的拉取等待是独立的，所以如果每个分区的消息都没到60KB，就会各自触发10秒等待，然后依次拉取，形成你看到的3个小批次。

接下来给你几个落地的解决方案，按复杂度从低到高排：

一、调整原生配置，最大化接近需求 #

这是最简单的方式，不用写任何自定义代码，只需要改几个配置：

• 把spring.kafka.consumer.fetch-min-size改成1，取消单分区的大小限制，只要分区有消息就会触发拉取，不用等凑够60KB
• 保留spring.kafka.consumer.fetch-max-wait=10000，确保低流量下每个分区最多等10秒就返回可用消息
• 把spring.kafka.consumer.max-poll-records设为100，这是单次拉取的全局总条数上限，高流量下消费者会从所有分区拉取消息，直到凑够100条，直接形成你想要的大批次
• 确保开启spring.kafka.listener.batch-mode=true（如果还没开的话），这是Spring Kafka批量监听的基础配置
• 把idle-between-polls直接删掉或者设为0，这个参数是两次拉取之间的强制间隔，高流量下会拖慢处理速度，完全没必要

这样配置后：

• 高流量场景：消费者会一次性从所有分区拉取消息，直到凑够100条，直接交给监听器处理，完美符合你的需求
• 低流量场景：如果10秒内所有分区的消息加起来够100条，会一次性拉取形成大批次；如果不够，10秒后会把所有分区的可用消息合并成一个批次处理，不会再出现3个小批次间隔10秒的情况——除非消息是陆续分10秒到达不同分区的，这是Kafka原生拉取模型的限制，没办法完全避免，但已经是最优解了

二、轻量自定义缓存（无需重写监听器） #

如果上面的配置还是不能满足你的“严格凑够100条才处理，除非等满10秒”的硬需求，那可以在现有批量监听器里加一层简单的缓存，不用写整个自定义监听器实现：

• 首先，在你的监听器类里维护一个线程安全的队列（比如ConcurrentLinkedQueue），用来缓存收到的所有消息
• 每次监听器收到批次消息时，把所有消息都加入队列
• 然后做两个判断：
  1. 如果队列里的消息数>=100，就取出前100条处理，处理完再手动提交偏移量
  2. 如果队列里的消息数<100，就启动一个单例的10秒定时器（注意要避免重复启动，比如用AtomicBoolean标记是否已有定时器在运行），时间到后取出队列里所有消息处理，同样处理完再提交偏移量
• 偏移量提交要改成手动模式（spring.kafka.listener.ack-mode=MANUAL_IMMEDIATE或者MANUAL），用Acknowledgment参数来控制提交时机，避免消息丢失

这种方式比重写监听器简单太多，就是在现有逻辑上加了一层缓存，完全可控。

三、不要踩的坑 #

最后提醒你几个容易踩的雷：

• 别用idle-between-polls，这个参数是强制两次拉取之间的间隔，高流量下会让你处理速度慢到怀疑人生
• 不要调整partition.assignment.strategy，这个是用来分配分区给不同消费者的，和跨分区合并批次完全没关系
• 不要盲目增大max-poll-interval.ms，这个参数是消费者的超时时间，设太大可能导致分区被重新分配

总结一下：如果你的需求不是“必须严格凑够100条才处理”，那第一种配置调整就完全够用；如果有硬需求，第二种轻量缓存的方式也很容易实现，不用写复杂的自定义监听器。你可以先试试第一种配置，应该能解决大部分问题！