企业官网建设流程全解析

1. 项目概述

1.1 核心需求解析

Spring整合Kafka，这个标题看着简单，实际做起来却有不少门道。我接触这个技术栈也踩了不少坑，从最早的Kafka 0.8版本一路用到现在，Spring Kafka从最初只能配合Spring Boot使用，到如今已经能完美嵌入Spring生态的各种场景，整个演进过程确实值得拿出来聊一聊。

先说清楚一件事：这里的“整合”不是简单地把两个依赖放进pom.xml就完事，而是要让Spring的IoC容器、事务管理、异常处理机制跟Kafka的消息生产消费生命周期无缝衔接。说得更直白一点，就是用Spring的方式去写Kafka代码——你去实现一个Listener，Spring帮你管理连接、管理线程、管理反序列化、管理重试和死信，而不是你自己去new一个KafkaConsumer然后手动poll。

适合谁来读这篇文章？正在做微服务改造、需要引入消息队列做异步解耦的Java后端开发者，或者已经在项目里用了原生Kafka客户端、想升级到Spring Kafka又不知道怎么下手的朋友。这篇文章会把核心原理、配置要点、实操步骤、踩坑实录都过一遍，尽量做到看完就能在自己的项目里落地。

1.2 为什么选择Spring Kafka而非原生客户端

直接使用Kafka原生客户端并不复杂，无非就是构造Properties，创建KafkaProducer和KafkaConsumer，然后写循环拉取消息。但一旦放到真实业务里，你会发现要操心的事情远比想象中多：消费者线程管理、消息确认机制、异常重试策略、批量消费、并发控制、消息转换……

这些工作如果全部自己实现，代码量会非常可观，而且很容易写出难以维护的重复代码。Spring Kafka在原生客户端之上做了一层很好的封装，它把连接管理交给Spring的Bean生命周期，把消费监听做成注解驱动，把序列化反序列化做成可插拔的组件，把事务消息和死信队列这些高级特性也一并收纳。对我来说，最直观的感受是：业务代码里几乎看不到Kafka的连接细节，剩下的全是跟业务直接相关的逻辑。

2. 环境准备与依赖配置

2.1 基础依赖引入

不管你是Maven项目还是Gradle项目，第一步都是引入依赖。我这里以Maven为例：

<dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> <version>3.1.2</version> </dependency>

如果你用的是Spring Boot，建议直接使用Spring Boot的依赖管理版本，不需要手动指定版本号。以Spring Boot 3.2.x为例，它管理的spring-kafka版本是3.2.x，直接引入即可：

<dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> </dependency>

注意：Spring Boot 2.x对应spring-kafka 2.x，Spring Boot 3.x对应spring-kafka 3.x，版本不要混用。尤其注意spring-kafka 3.0开始要求JDK 17，如果你的项目还在JDK 8上，请继续使用2.x版本。

另外Kafka服务端版本和客户端库版本之间的兼容性也需要注意，一般原则是客户端可以连接更高版本的broker，但不建议客户端版本远旧于服务端版本，避免错失新特性。我目前的经验是：服务端3.x配合客户端3.x用起来最省心。

2.2 基础配置项说明

引入依赖还不够，你需要把连接信息告诉Spring。最基础的一组配置：

spring: kafka: bootstrap-servers: localhost:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer consumer: key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer group-id: demo-group auto-offset-reset: earliest

这里的bootstrap-servers是Kafka集群的地址列表，生产环境建议至少配置两个以上broker的地址，避免单点问题。key/value的序列化和反序列化器决定了消息在网络上传输时的字节转换方式。group-id是消费者组的标识，同一消费者组内的多个消费者实例会分摊topic分区的消息，这个机制是Kafka实现水平扩展的基础。

这些配置看起来平淡无奇，但后面全部有文章可做。比如auto-offset-reset这个参数，它的取值earliest和latest对应的语义完全不同：earliest表示从最早的消息开始消费，适合新消费者组第一次启动时不想丢消息的场景；latest表示只消费启动之后新产生的消息，适合对历史消息不感兴趣的场景。线上环境里这两个值选错，轻则重复消费一堆历史消息，重则丢掉明显该处理的业务数据。

3. 生产者端的整合实践

3.1 KafkaTemplate的使用

Spring Kafka对生产者端的主要封装是KafkaTemplate。注入之后直接发消息，代码长这样：

@Service public class OrderMessageProducer { @Autowired private KafkaTemplate<String, String> kafkaTemplate; public void sendOrderMessage(String orderId, String message) { kafkaTemplate.send("order-topic", orderId, message); } }

这个send方法有三个关键参数：topic表示目标主题，这里的key是消息键，用于决定消息进入哪个分区。关于分区规则，如果不指定key，消息通过轮询方式分散到各个分区；指定key的话，相同key的消息总是进入同一分区，这保证了同一业务键的消息在消费端能按顺序处理。

但实际项目中我很少直接发送String，更多是发JSON字符串，或者自定义对象配合JsonSerializer。用自定义对象的写法是配置一个ProducerFactory，把value-serializer换成JsonSerializer：

@Bean public ProducerFactory<String, OrderEvent> producerFactory() { Map<String, Object> props = new HashMap<>(); props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class); props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, JsonSerializer.class); return new DefaultKafkaProducerFactory<>(props); } @Bean public KafkaTemplate<String, OrderEvent> kafkaTemplate() { return new KafkaTemplate<>(producerFactory()); }

3.2 发送确认与回调机制

发消息不能只关心发出去了，还得知道到底成没成功。Kafka的生产确认机制有三个级别：acks=0、acks=1、acks=all。默认配置下Spring Kafka用的是acks=1，表示leader收到消息就返回成功；如果追求不丢消息，应该设置acks=all，表示所有ISR副本都写入成功才算成功。

请求确认级别配置如下：

spring: kafka: producer: acks: all

同时代码里要用回调来感知发送结果：

public void sendMessageWithCallback(String message) { ListenableFuture<SendResult<String, String>> future = kafkaTemplate.send("order-topic", message); future.addCallback(new ListenableFutureCallback<>() { @Override public void onSuccess(SendResult<String, String> result) { System.out.println("消息发送成功, offset = " + result.getRecordMetadata().offset()); } @Override public void onFailure(Throwable ex) { System.err.println("消息发送失败: " + ex.getMessage()); } }); }

心得：回调里不要只做日志打印，更好的做法是把失败消息记录下来，配合定时任务做补偿重发。消息队列存在的意义就是可靠性，如果丢了消息业务上还感知不到，那引入MQ反而成了隐患。

3.3 生产者端常见问题

消息体过大是一个常见坑。Kafka默认的单条消息大小限制是1MB，生产者发送超限消息会直接抛异常。如果有大消息需求，需要调broker端和client端的两个参数：

spring: kafka: producer: max-request-size: 10485760 # 10MB

另外记住，加了压缩是提升吞吐的首选手段。对文本型消息使用lz4或zstd压缩，CPU开销小，还能显著降低网络带宽占用。Kafka客户端默认的compression-type是none，在高吞吐场景记得改掉它。

4. 消费者端的整合实践

4.1 注解式监听器

Spring Kafka消费端的核心是@KafkaListener注解，这是整个整合体验里最舒服的部分：

@Component public class OrderMessageConsumer { @KafkaListener(topics = "order-topic", groupId = "order-service") public void onOrderMessage(ConsumerRecord<String, String> record) { String orderId = record.key(); String message = record.value(); System.out.println("收到订单消息: " + orderId + " - " + message); } }

就这么简单，一个方法就成为了一条消息的消费入口。Spring后台会为你创建监听容器，管理线程和拉取循环。默认情况下，这个监听器所在容器会从配置的group-id拉取消息并自动提交偏移量，整个过程对业务代码几乎透明。

@KafkaListener还有几个实用属性值得展开说说。concurrency属性控制并发消费线程数，它直接影响监听容器的消费者数量。例如concurrency=3表示这个监听器会生成3个消费者实例，分布在同一个消费者组内。需要特别注意一个数学关系：消费者数量不能超过topic的分区数，否则多余的消费者会空转，拿不到任何消息。

errorHandler可以指定一个异常处理器Bean，当监听方法抛出异常时触发。这个后面会详细聊重试和死信。

4.2 消息确认模型

默认的自动确认模式让人省心，但也有隐患：如果消息处理逻辑抛出异常，Spring会根据配置决定是重试还是直接提交偏移量。默认情况下，异常消息会被记录下来，偏移量继续提交，然后消息就丢了。对于不允许丢消息的业务，一定要切换成手动确认模式。

手动确认的配置分两步。第一步设置确认模式为MANUAL：

spring: kafka: listener: type: batch # 或 single consumer: enable-auto-commit: false

第二步在代码里手动调用acknowledgment：

@KafkaListener(topics = "order-topic", groupId = "order-service") public void onOrderMessage(String message, Acknowledgment ack) { try { processOrder(message); ack.acknowledge(); } catch (Exception e) { // 失败不确认，消息不会被标记消费 log.error("订单消息处理失败", e); } }

确认模型的选择本质是at-most-once和at-least-once之间的权衡。自动提交更接近at-most-once，因为它在拉取后就提交，不关心你是否处理成功；手动确认更接近at-least-once，因为只有处理成功后你才会确认，失败则会在下次拉取时再次收到。

但at-least-once带来的副作用是重复消费。假设你确认前进程崩溃了，消息会被重新消费一遍。所以消费者端的业务逻辑一定要设计成幂等的，用订单号、消息ID做去重是基本要求。这个逃不掉，无论用什么消息队列，只要选择了at-least-once，幂等就是必修课。

4.3 消费者端常见问题

分区分配不均衡的问题是真实存在且常见：某个消费者的分区数量远多于其他消费者，导致部分消费者忙死、部分消费者闲死。一般出现这种现象要先看topic的分区数和消费者组里的实例数是否匹配，再看看各实例的负载情况。如果分区数大于消费者数，再加消费者数量也不会有更多消息吞吐，这时要扩展的是分区数。

另外还有一个很多人会踩的坑：@KafkaListener注入的Bean如果是用JDK动态代理生成的，可能出现方法找不到的情况。确保监听器类没有被意外地设计成final类，方法也不要用private修饰，否则Spring AOP代理链可能无法正常触发。

5. 序列化与反序列化方案

5.1 消息格式选型

String就够用的场景自然不必折腾，但一旦消息体是复杂对象，选对序列化方案直接决定后续开发和排障的体验。

我在项目里见过不少直接把Java对象用JDK原生序列化后发到Kafka的，结果就是消费端反序列化时还要依赖同一个类定义，服务一拆就崩。还有用自定义二进制格式的，debug的时候看消息内容全是一堆乱码，排查问题非常痛苦。

现在主流的选型基本是JSON或者Avro。JSON的好处是直观、跨语言、可读性强，配合Jackson或者Gson使用起来极其方便；缺点是schema演进上完全靠自觉，字段变更时生产者和消费者之间需要额外约定。Avro配合Schema Registry则把schema管理交给了统一组件，字段增减能自动兼容，但对组件的部署运维有一定要求。

我自己的折中方案是：内部服务之间用JSON快速迭代，跨团队、长期稳定的核心链路上才考虑引入Avro。

5.2 JSON序列化实战

Spring Kafka对JSON的支持用起来很方便，配置好JsonSerializer和JsonDeserializer即可。消费者端的配置略复杂，因为泛型类型信息需要额外指定：

spring: kafka: consumer: value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer

同时代码里要告诉反序列化器目标类型：

@Bean public ConsumerFactory<String, OrderEvent> consumerFactory() { Map<String, Object> props = new HashMap<>(); props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class); props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, JsonDeserializer.class); props.put(JsonDeserializer.TRUSTED_PACKAGES, "*"); return new DefaultKafkaConsumerFactory<>(props, new StringDeserializer(), new JsonDeserializer<>(OrderEvent.class)); }

这里有个关键配置：TRUSTED_PACKAGES。JsonDeserializer默认只信任java.util和java.lang包下的类，如果你要反序列化的是自己定义的业务对象，就必须把这个白名单放开。

5.3 序列化与兼容性陷阱

消息发送之后类型变了怎么办？比如v1版本的OrderEvent有五个字段，v2版本删掉一个字段或增加一个字段。JSON序列化容忍新增字段，但反序列化时多余字段默认会被忽略，所以字段删减在JSON场景下往往能混过去。不过要注意：消费端依赖的字段如果缺失，可能反序列化出来的对象字段值是null，等真正用的时候才暴露空指针问题。

我给团队定过一条规矩：生产者和消费者之间的消息契约要放到单独的模块里管理，任何字段变更必须先在消费端验证兼容性再上线。这比事后排查线上事故要省心得多。

6. 重试机制与死信队列

6.1 消费重试的几种实现

消费消息总是会失败，网络抖动、下游服务超时、数据格式不合规，各种原因都有。重试机制是保证消息最终被处理的兜底手段。

最简单的方案是在@KafkaListener方法内部自己写try-catch重试：

@KafkaListener(topics = "order-topic", groupId = "order-service") public void onOrderMessage(String message) { int retryCount = 3; while (retryCount > 0) { try { processOrder(message); break; } catch (Exception e) { retryCount--; if (retryCount == 0) { throw e; } Thread.sleep(1000); } } }

这种写法直白，但问题也不少：阻塞了消费者线程、重试间隔没有退避策略、消息偏移量迟迟不提交，如果下游恢复需要一段时间，这种方案反而会把消费者拖垮。

更好的选择是使用Spring Kafka自带的SeekToCurrentErrorHandler（在2.x中是ErrorHandler，3.x中已经改名为DefaultErrorHandler）。它的做法是：当监听方法抛出异常时，把当前消息的offset回退，让消费者重新拉取这条消息，重试达到上限后，把消息转发到死信topic。配置方式：

@Bean public DefaultErrorHandler errorHandler(KafkaTemplate<String, String> kafkaTemplate) { // 最多重试4次，每次间隔1秒 return new DefaultErrorHandler( new FixedBackOff(1000L, 3), (record, exception) -> { // 将失败消息转发到死信队列 kafkaTemplate.send("order-topic.DLT", record.value()); } ); }

6.2 死信队列的设计

死信队列是消息队列领域的通用思路：多次重试仍然失败的消息，单独放到一个专门的topic里，由额外的人工补偿逻辑去处理。这样既不会阻塞主链路的消费，也不会让失败消息凭空消失。

死信topic的命名一般沿用原topic名加后缀。比如order-topic的死信是order-topic.DLT。死信消费端要做的事情通常是告警和记录，或者把消息内容持久化到数据库，等待后续人工处理。一套完整的消息处理链路上，死信队列是不可或缺的，它承担了“兜底保障”的职责。

关于间隔退避，我自己的实践是不要使用固定的1秒重试4次。对下游暂时性故障的场景，线性退避往往不够，指数退避更合适：

new ExponentialBackOff(1000L, 2.0)

这个配置的含义是：初次间隔1秒，之后每次间隔翻倍，重试次数上限视业务而定。指数退避的核心思想在于，下游故障通常不会在几秒内自动恢复，频繁重试只会增加下游压力和无效的网络请求。

6.3 重试机制的注意事项

自动重试虽然让代码简洁，但要注意它默认情况下在同一个消费者的线程里执行。也就是说，一条消息占着重试线程的时间，其他分区的消息就无法被消费。如果重试次数多且间隔长，整个消费者的吞吐量会急剧下降。

我建议对重试时间敏感的业务，比如订单处理、支付回调，不要设置过长的重试窗口。重试两三次之后直接走死信或者告警，让专门的补偿任务去处理，比在消费线程里死磕要健康得多。

7. 事务消息与幂等性设计

7.1 Kafka事务最简入门

Kafka的事务机制不像数据库事务那样覆盖广泛，它的核心能力是多个消息发送要么都成功、要么都失败，还允许把“消费消息”和“发送消息”纳入同一个原子操作。这个特性在需要“读消息->写数据库->发消息”的典型场景里非常有用。

Spring Kafka对事务支持得相当好。开启事务只需要配置一个事务管理器：

@Bean public KafkaTransactionManager<String, String> transactionManager( ProducerFactory<String, String> producerFactory) { return new KafkaTransactionManager<>(producerFactory); }

然后在发送端方法上加@Transactional注解即可。这里有个容易被忽略的细节：事务生效的前提是KafkaTemplate的事务型ProducerFactory，而不是普通的DefaultKafkaProducerFactory，需要一个特定设置：

@Bean public ProducerFactory<String, String> producerFactory() { DefaultKafkaProducerFactory<String, String> factory = new DefaultKafkaProducerFactory<>(producerProps()); factory.setTransactionIdPrefix("tx-"); return factory; }

transactionIdPrefix这个参数很重要，Kafka通过它生成唯一的transactional.id，用于实现生产者的会话隔离和事务恢复。如果多个服务实例共用同一个前缀，会引发ProducerFencedException。解决办法是让前缀带上实例标识，比如应用名加随机后缀。

7.2 幂等消费的设计思路

我反复强调幂等性，这儿再补充一些具体的设计手段。最简单的幂等方案：利用数据库唯一键去重。在消费消息时，把消息ID插入一张去重表，插入成功说明这条消息从没处理过，插入失败说明已经处理过，直接跳过。

@KafkaListener(topics = "order-topic", groupId = "order-service") public void onOrderMessage(String message) { String messageId = extractMessageId(message); try { dedupService.markAsProcessing(messageId); processOrder(message); dedupService.markAsCompleted(messageId); } catch (DuplicateKeyException e) { log.info("重复消息，跳过处理: {}", messageId); } }

这个方案有几个细节值得注意：

• 去重表的记录要设置过期时间，否则会无限膨胀。一般按业务消息保底时间来定，比如7天。
• 去重和业务操作要在同一个数据库事务里完成，避免“业务执行成功但去重标记未提交”的情况。
• 复杂场景下可以用Redis的SETNX来做瞬时去重，但最终对账还是得靠数据库唯一键。

7.3 事务的局限与补偿

事务不是银弹。Kafka事务只能保证“消息发送”层面的原子性，并不能覆盖到你业务系统里的一切动作。比如你消费了一条消息，扣了数据库里的库存，然后发送“库存扣减成功”的事务消息，这两件事情分属数据库事务和Kafka事务，并没有一个统一的全局事务把它们纳入同一个原子单元。如果数据库事务提交成功，但Kafka事务提交失败，会发生什么？库存扣了，消息没发出去，上下游数据不一致。

这种场景需要引入本地消息表或者分布式事务框架。本地消息表的思路是：在业务数据库里建一张消息表，业务更新和消息表插入在同一个数据库事务里完成，然后有一个定时任务扫描未发送的消息，把消息发到MQ，收到发送成功的回执后把消息表标记为已发送。这么一来，消息的可靠性和业务数据的一致性由同一个数据库事务来兜底，比强行追求分布式事务要简单可靠得多。

8. 监听容器与并发控制

8.1 Concurrency与分区分配规则

concurrency这个参数前面提过一嘴，这里展开细聊。Kafka的并行消费能力由两个因素决定：topic的分区数和消费者组内的消费者数量。实际吞吐能力等于这两个数字中较小的一个。

举一个具体例子。假设你设置了concurrency=5，但topic的分区数只有3，那么只有3个消费者能拿到分区，剩下2个消费者完全空闲。反过来，如果topic有10个分区，你只设置了concurrency=2，那么最多同时消费2个分区。所以规划并发度的第一步，是确认topic的分区数是否支撑你的目标吞吐量。

调整分区数可以用命令行工具，也可以用管理脚本，具体命令不在本文展开。需要注意的是，分区数只能增加，不能减少，所以创建topic时最好一次性规划好半年的增长空间。

8.2 批量监听与批量处理

默认情况下，@KafkaListener每次调用方法处理一条记录。如果你的业务允许批量处理，切换成List类型入参可以显著提升效率。切换方式：

@KafkaListener(topics = "order-topic", groupId = "order-service", containerFactory = "batchFactory") public void onBatchMessage(List<ConsumerRecord<String, String>> records) { List<OrderEvent> events = records.stream() .map(record -> deserialize(record.value())) .toList(); // 批量写库或者批量调下游 }

对应的ContainerFactory配置也需要改成batch类型：

@Bean public KafkaListenerContainerFactory<Object> batchFactory() { ConcurrentKafkaListenerContainerFactory<String, String> factory = new ConcurrentKafkaListenerContainerFactory<>(); factory.setBatchListener(true); return factory; }

批量处理更高效的底层逻辑也很清楚：减少网络请求次数、减少数据库连接占用、减少框架层的调度开销。但批量处理同时也意味着容错更难做：这批消息里有一条失败的，整批要不要重来？这取决于你的业务逻辑能不能对单条记录做精细的异常隔离。我的实践是：批量处理适合离线类、日志类场景；在线业务里还是单条处理更可控。

8.3 消费者的优雅启停与分区分配监听

生产环境里经常需要动态调整消费者组的分区分配，比如扩缩容消费者实例。Spring Kafka提供了ConsumerRebalanceListener，可以在分区被回收或分配时执行自定义逻辑。

比较典型的用法是在分区回收前提交偏移量，避免rebalance之后的重复消费。另一个用法是在分区分配完成后预热本地缓存。实现方式：

@Bean public ConsumerFactory<String, String> consumerFactory() { DefaultKafkaConsumerFactory<String, String> factory = new DefaultKafkaConsumerFactory<>(consumerProps()); factory.setConsumerPostProcessor(consumer -> consumer); return factory; }

不过大多数场景下我们不需要直接使用RebalanceListener，理解它的存在即可，Spring Kafka在内部已经处理了大部分情况。

9. 监控与运维实战

9.1 关键指标与监控方案

消息队列在生产中属于基础设施，必须要有监控。Kafka自身暴露了大量的JMX指标，Spring Kafka也提供了若干可以用于度量追踪的接口。我建议重点盯这几个指标：

• lag：消费者落后生产者的消息堆积量，这个指标能直接反映消费是否健康。
• 消费速率：每秒处理的消息数，速率骤降往往意味着瓶颈或异常。
• 重试次数与死信数量：这两个指标能反映消息链路的异常比例。
• 生产者的发送成功率与延迟：这个指标反映了生产端到broker的链路质量。

监控工具上，Prometheus加Grafana是主流方案。如果Spring Boot项目里接了Micrometer，可以通过micrometer-registry-prometheus直接暴露Kafka消费指标。配置依赖地址后，Spring Boot会自动接入Kafka消费者和生产者相关的指标。

9.2 日志排查与消息链路追踪

消息从生产端到消费端，跨越了网络和服务，排障时必须把消息的流转过程串联起来。我的做法是在消息体里内置一个traceId，生产者生成它，消费端和下游服务在日志里打印它。这样一条消息在处理链路任何一环出了问题，都能通过traceId把日志串起来看。

Spring Kafka的ConsumerRecord里可以读取消息头，常见的做法是在发送端把traceId放入header：

kafkaTemplate.send("order-topic", orderId, message, Map.of("traceId", traceId));

消费端读取header：

@KafkaListener(topics = "order-topic") public void onMessage(ConsumerRecord<String, String> record) { String traceId = new String(record.headers().lastHeader("traceId").value()); // 把这个traceId放进MDC，日志里就能自动携带 MDC.put("traceId", traceId); }

这套做法简单有效，不需要引入全链路追踪系统就能先撑起来。等链路复杂到一定程度，再考虑引入分布式追踪框架，但前提是消息里的traceId体系已经建立好，否则接什么都麻烦。

9.3 压测与容量规划

提醒所有打算在生产环境大规模使用Kafka的团队：上线前一定要做一次压测，确定你的topic分区数、消费者并发度、broker磁盘和网络带宽的上限在哪里。

压测的核心是用生产场景的真实消息体大小和速率来摸高，而不是用空字符串跑一遍完事。消息大小直接决定了网络IO和磁盘IO的开销，1KB和1MB消息在吞吐性能上是天壤之别。我们之前做个一个订单系统的压测，消息体平均800字节，3个分区、3个消费者实例，消费端单实例吞吐能达到每秒3000条左右；而另一个日志采集场景，消息体平均50KB，同样的配置直接掉到每秒200条，后来加了分区数和消费者数量，还开启了压缩才压住。

10. 常见问题速查表

我把这几年遇到的典型问题整理成一张速查表，方便你排查时直接对号入座。

现查表只能帮你定位方向，具体排查还要结合日志和监控数据。有一个排查技巧值得分享：搭一套本地的Kafka环境，用同样的消费者代码复现问题，这样能把网络、broker配置、其他业务干扰因素全部隔离开来，快速定位到消费端还是broker端。

注意：任何一个线上Kafka问题的排查，第一步永远是看消费组的lag和消费者实例状态，这两种数据反映了消息队列最核心的健康状况。很多问题从这两个指标能直接判断出方向，不用一开始就深挖日志。

11. 总结要点回顾

Spring整合Kafka这件事，从配置到落地，本质上是在Kafka原生能力与Spring开发习惯之间搭一座桥。生产的可靠性由acks、重试、回调来保障；消费的可靠性由确认机制、幂等设计、死信队列来兜底；全链路的可观测性则靠指标监控与traceId串联完成。没有一劳永逸的配置模板，每个环节的选择都依赖具体的业务场景。事务与幂等设计是最容易被忽略也最致命的部分，强烈建议在项目初期就把消息契约和去重策略定下来，不要等线上出现重复数据再回头补。

就我个人经验来说，稳定性做得好的消息系统，往往不是靠某个框架特性，而是靠做事方式——消息契约有人管理、消费端有监控、失败有兜底方案。Kafka本身已经足够成熟，真正拉开差距的是使用方对细节的把控。