本文用JMH基准测试证明，Kafka生产者开启幂等性后吞吐量仅下降约1-2%，在单节点和三节点集群中差异均处于正常测量误差范围内。幂等性通过Producer ID和序列号机制在协议层实现去重，无需应用层处理。自3.0版本起默认开启，只要配置acks=all、retries>0、max.in.flight.requests.per.connection<=5即可生效。除非追求极限吞吐量且允许重复数据，否则建议保持开启以获得Exactly-Once语义保障。
幂等性是个啥玩意儿
想象一下你正在玩一个射击游戏，按下射击键一次，子弹飞出去一发，这是正常操作。但如果你手抖了，不小心连按了三下，结果只应该打出一发子弹，却飞出去三发，这就乱套了。幂等性就是那个防止你手抖的机制——不管按多少次，结果和按一次完全一样。
在Kafka这个世界里，生产者就是那个射击手，消息就是子弹。网络抽风、服务器宕机、请求超时，这些破事儿随时可能发生。生产者一看没收到确认，心里慌得一批，赶紧重试发送。没有幂等性的话，同一条消息可能就被写进去好几遍，消费者那边收到三条"您的订单已支付"，估计要疯。
幂等性开启后，Kafka在协议层面就帮你把这事办了。
每个生产者实例拿到一个独一无二的Producer ID，简称PID，就像你的身份证号。每条消息还带个序列号，相当于这条消息的排队号码。Broker收到消息后一看，哟，这个PID的这个序列号刚才已经处理过了，直接扔掉，不会重复写入。
整个过程你作为应用开发者完全不用操心，不用写一堆复杂的去重代码，不用搞什么数据库唯一索引，Kafka自己就在底层搞定了。
这个机制从Kafka 3.0版本开始变成了默认开启，说明官方觉得这事太重要了，大家应该无脑用起来。
当然，想手动控制也可以，设置enable.idempotence=true就行。
但要注意几个配套设置：
acks必须设为all，确保消息真正被所有副本写好了才算成功。
retries要大于0，推荐直接用默认值Integer.MAX_VALUE，表示无限重试。
max.in.flight.requests.per.connection不能超过5，这是为了保证消息顺序不会乱。
如果这几个设置冲突了，比如你把acks设为1，还硬要开启幂等性，Kafka客户端会直接抛异常，告诉你这配置不靠谱。
生产者行为大变身
开启幂等性后，生产者和Broker之间的互动方式会发生一些微妙但关键的变化。首先，Broker给生产者发PID的时候，就像给新员工发工牌，以后干活都得带着这个工牌。生产者每次发消息批次的时候，都会在这个批次上贴上序列号标签，就像给快递包裹贴单号。
Broker这边收到包裹后，会仔细检查工牌和单号。如果发现同一个工牌同一个单号的包裹已经签收过了，直接拒收，告诉生产者"这单我已经处理过了"。生产者收到这个反馈后，就知道不用重发了。如果生产者没收到任何反馈，心里没底，就会按照之前的PID和序列号重新发送，Broker一看是重复的，依然拒收，但不会报错，整个过程很和谐。
这里有个关键点，acks=all的设置让生产者必须等到Broker确认消息已经被所有副本写入后，才敢发下一批。这就好比你去餐厅吃饭，点完菜后必须等到服务员确认"菜已经放在所有桌上了"，而不是只听一个服务员说"我收到了你的订单"。这种等待确实会引入一些延迟，但换来的是绝对的安全性。
序列号必须是严格递增的，这是硬性要求。如果允许太多并发请求在飞，比如把max.in.flight.requests.per.connection设得很大，就可能出现序列号乱序的情况。Broker收到序列号5之后突然收到序列号7，中间缺了个6，就会懵圈，不知道6是丢了还是延迟了。所以Kafka强制要求这个值不超过5，这是经过大量实践验证的安全线。
这种机制带来的代价就是并行度降低和性能损耗。生产者得等确认，不能无脑狂发。序列号检查也增加了一点计算开销。但就像你为了数据安全愿意多花点钱买块好硬盘一样，这点性能损耗换来的是消息不重复的承诺，在大多数场景下是完全值得的。
还有一个重要细节，幂等性只在生产者活着的时候有效。如果生产者进程重启了，PID就变了，序列号也从0重新开始计数。这时候如果之前有些消息其实发送成功了，但生产者重启后不知道，重发一遍，Broker会认为是新生产者的消息，不会去重。要解决这个问题，需要引入事务机制，把生产者的状态持久化下来，但这又是另一个话题了。
性能测试实战
光说不练假把式，咱们来看看实际测试数据。
用Java Microbenchmark Harness，简称JMH，做了个严谨的基准测试。JMH是Java世界里最专业的性能测试工具，能排除JVM预热、垃圾回收、CPU调度等各种干扰因素，给出可信的结果。
测试环境用Docker Compose搭建，这样每次测试条件完全一致，可重复性强。分为两种场景：一种是单机版，就一个Broker，没有副本复制，简单粗暴。另一种是三节点集群，复制因子设为3，更接近生产环境。
生产者配置除了幂等性开关不同，其他都保持一致。
acks=all是必须的，retries设为无限大，max.in.flight.requests.per.connection设为5。还加了一些优化参数减少测试波动，比如linger.ms=5让消息稍微攒一攒再发，batch.size=32KB控制批次大小，compression.type=none关闭压缩避免CPU干扰，各种超时时间也设得比较长确保网络抖动不会影响结果。
测试方法是用异步发送，先发一堆消息拿到Future对象，然后统一等待所有Future完成。这样测量的是真正的端到端吞吐量，包括生产者发送、Broker处理、副本同步、确认返回的完整流程，而不是只看生产者本地缓冲区的写入速度。
单节点测试结果
先来看单机无副本的场景，这是最简单的情况，理论上性能最高。
开启幂等性的生产者，吞吐量达到了24891.897条消息每秒。
关闭幂等性的版本，吞吐量是24953.439条每秒。
两者相差大概61条每秒，相对差距不到0.25%。
这个差距小到可以忽略不计，属于正常的测量误差范围。你可以理解为，在实验室里用同样的仪器测同一个东西，两次结果也不可能完全一样，总会有点波动。
这个结果表明，在没有副本复制的压力下，幂等性带来的序列号管理和PID维护开销极小。Broker处理单条消息的速度本身就很快，那点额外的检查工作就像大象身上多背了根稻草，根本感觉不到重量。
三节点集群测试结果
接下来看真正的生产环境模拟，三个Broker组成集群，复制因子为3。这意味着每条消息要被写入三个不同的机器，网络传输和磁盘写入的压力都大了不少。
开启幂等性的吞吐量是23689.246条每秒，关闭的是24097.398条每秒。差距扩大到大概408条每秒，相对差距约1.7%。虽然比单节点场景明显了一些，但依然是个非常小的数字。在24000条每秒的基数面前，1.7%的波动就像你一个月工资两万块，少了三百多块，可能都没注意到。
更有趣的是，在某些测试运行中，开启幂等性的生产者甚至偶尔得分比关闭的还高。这说明性能测试本身就有随机性，CPU缓存命中率、磁盘IO调度、网络延迟的微小变化，都可能影响结果。1.7%的差距完全落在这个随机波动范围内，不能说明关闭幂等性真的更快。
这个测试结果非常鼓舞人心。很多人担心开启幂等性会严重拖慢性能，特别是在高吞吐场景下。但数据告诉我们，这种担心是多余的。Kafka的工程师在实现这个特性时做了大量优化，PID分配和序列号检查的效率极高，不会成为瓶颈。
什么时候该开什么时候该关
基于测试结果和Kafka的设计哲学，我们可以给出明确的建议。幂等性在Kafka 3.0之后默认开启，这是有道理的。它提供的价值——防止消息重复——远远超过了它付出的代价——约1-2%的吞吐量损耗。
如果你正在构建一个订单系统、支付系统、库存系统，或者任何对数据准确性要求高的应用，重复消息就是灾难。一个订单被处理两次，钱被扣两次，库存被减两次，这些错误比系统慢个1%要严重得多。在这种情况下，幂等性必须开着，没什么好犹豫的。
即使你的业务能容忍一定程度的重复，比如日志收集、点击流分析，开启幂等性也是个稳妥的选择。1%的性能损失几乎可以忽略，但你获得了更强的容错能力。网络抖动、Broker重启、生产者重连，这些常见故障都不会导致数据问题，系统更健壮，你睡得更香。
唯一需要考虑关闭幂等性的场景，是你确实在追逐极限性能，而且业务完全不在乎重复数据。比如你在做一个实时 metrics 采集系统，每秒要处理几十万条指标，丢几条重几条无所谓，只要大致趋势对就行。这时候你可以关闭幂等性，把那点开销省下来。但即便如此，建议先开着做压力测试，看看瓶颈到底在哪。很多时候你以为的性能问题，其实根本不是幂等性造成的。
配置检查清单
想要确保幂等性真正生效，这里有个快速检查清单。首先确认你的Kafka客户端版本是3.0或更高，这样默认就是开启的。如果你显式设置了enable.idempotence=true，那就要注意几个配套参数。
acks必须等于all，不能是1或0。acks=1表示只要Leader副本写入成功就返回确认，这时候如果Leader挂了，消息可能丢失，幂等性保证就失效了。acks=0表示生产者发完就不管了，连重试都没有，更谈不上幂等。
retries要大于0，建议直接用默认值。如果你设了retries=0，生产者遇到错误直接抛异常，不会重试，幂等性机制根本用不上。
max.in.inflight.requests.per.connection不能超过5。如果你为了追求并发度把这个值设得很高，比如10或100，Kafka会拒绝启动生产者，或者在运行时破坏幂等性保证。5是官方验证过的安全值，能保证消息顺序和去重机制都正常工作。
如果你从旧版本升级，或者接手了一个遗留系统，建议检查一下这些配置。有时候前人为了"优化性能"乱改配置，把幂等性搞没了，你还不知道。
背后的设计智慧
Kafka的幂等性设计体现了分布式系统领域的一个重要思想：在正确性和性能之间，优先保证正确性，同时尽量降低性能的代价。很多系统为了性能牺牲正确性，结果数据乱了，后面要花十倍百倍的精力去修复。Kafka反其道而行之，把正确性作为默认选项，性能损耗控制到几乎不可感知。
这种设计也反映了现代硬件和网络的发展。以前CPU慢、网络慢，每一点额外开销都很珍贵。现在CPU动辄几十核，网络带宽几十Gbps，协议层面的那点计算和传输开销真的可以忽略。反而是数据一致性、系统可靠性变得更加重要，因为数据量大了，一出错就是大事。
幂等性机制还展示了协议设计的力量。它不是应用层的补丁，而是从一开始就设计在Kafka协议里的。Producer ID和序列号的概念简单明了，却能解决复杂的分布式去重问题。这种在底层解决问题的思路，让应用开发者省心省力，不用每个项目都重新发明轮子。
总结
这篇文章通过严谨的JMH基准测试证明，Kafka生产者的幂等性特性对性能的影响微乎其微，在单节点场景下差异不到0.25%，在三节点集群场景下差异约1.7%，均处于正常测量误差范围内。
幂等性通过Producer ID和序列号机制在协议层实现去重，无需应用层干预，自Kafka 3.0起默认开启。
建议几乎所有场景都保持开启，除非追求极限吞吐量且业务完全容忍重复数据。配置时需注意acks=all、retries>0、max.in.flight.requests.per.connection<=5的配套要求。这是一次典型的以极小代价换取极大可靠性的优秀设计实践。