"Kafka怎么保证at-most-once、at-least-once、exactly-once三种投递语义？"
消息投递语义是Kafka面试的核心题，也是消息系统都要面对的取舍。"exactly-once"是大多数候选人最容易理解错的概念——是不是真的懂生产者和消费者两边都要配合，这道题直接区分。
先说定义：at-most-once（0次或1次，可能丢但不重复）、at-least-once（至少1次，不丢可能重复）、exactly-once（精确1次，最难）。
生产者侧：acks=0是at-most-once（发了不管）；acks=1或acks=all+retries是at-least-once（重试导致重复）；enable.idempotence=true配合acks=all，每个（producerID，seq）在分区上最多写一次，消除了生产者重试引起的重复。
消费者侧：关键是offset什么时候提交。先处理后提交——崩溃中间会重处理，at-least-once；先提交后处理——提交后还没处理完就崩了，消息丢失，at-most-once。
端到端exactly-once：Kafka 0.11开始支持事务，生产者在一个事务里原子地写输出topic并提交消费者offset。下游用isolation.level=read_committed只读提交的消息。
现实选择：真正的端到端exactly-once需要事务API或Kafka Streams。大多数生产系统用"at-least-once + 幂等消费"——消费端按消息key在DB里做去重，这种方式更简单也更健壮。
Kafka支持三种投递语义，但保证取决于生产者和消费者两边的配置。生产者侧：acks=0发完就走，at-most-once，网络抖动消息就没了。acks=1等leader确认，acks=all等所有ISR副本确认。acks=all + retries默认是at-least-once，因为网络超时会让生产者重试，broker会把同一条消息写两次。解法是enable.idempotence=true——Kafka给每个生产者分配一个producerID，在每个分区上维护单调递增的sequence number。broker拒绝重复的（producerID，seq）对，所以重试变成天然幂等。开启幂等后，单分区上生产者做到了exactly-once。消费者侧的关键是offset提交时机。先处理后提交——处理完和提交之间崩了，重启会重处理，at-least-once。先提交后处理——提交后还没处理完就崩了，消息丢，at-most-once。消费者→生产者的端到端exactly-once需要Kafka事务（0.11开始）。生产者beginTransaction、写输出消息、发送消费offset、commitTransaction——原子提交。下游消费者配isolation.level=read_committed，只能看到已提交事务的消息，看不到abort的。Kafka Streams内部就是用这套做exactly-once的。现实里很少有系统真的需要端到端exactly-once。大多数生产管道是"at-least-once + 幂等消费"——按message key在下游DB或服务里做去重。这种方式比真事务更简单，能处理更多失败模式（比如下游服务本身重试），是工业界主流选择。
开口要先澄清"exactly-once是端到端概念不只是生产者"，很多候选人这里就扣分。
能讲出enable.idempotence=true和（producerID，seq）机制是实战信号。
诚实说"生产上多是at-least-once + 幂等消费"是加分项。
忘了acks或isolation.level的具体值，即答侠可以实时提示。
不等于。幂等只防生产者重试重复，且只在单分区生效。端到端exactly-once要消费者-生产者事务。
吞吐量下降10-30%，延迟上升，因为要和事务协调器broker做类2PC的提交。
直接不能。跨集群复制（MirrorMaker 2）是at-least-once。需要目标端应用层做去重。