本文主要讲述了Kafka 消息交付可靠性保障以及精确处理一次语义的实现，具体包括幂等生产者和事务生产者。
所谓的消息交付可靠性保障，是指 Kafka 对 Producer 和Consumer 要处理的消息提供什么样的承诺。常见的承诺有以下三种：
最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。
至少一次（at least once）：消息不会丢失，但有可能被重复发送。
精确一次（exactly once）：消息不会丢失，也不会被重复发送。
目前，Kafka 默认提供的交付可靠性保障是第二种，即至少一次。也就是生产者发完消息给broker，这个时候broker中的消息已经成功提交，但是此时网络发生抖动，broker回传给producer的ACK丢失了，那么producer就会重试再发一次相同的消息，这个时候就会造成消息的重复性问题。Kafka 也可以提供最多一次交付保障，只需要让 Producer禁止重试即可。这样一来，消息要么写入成功，要么写入失败，但绝不会重复发送，但是会造成消息丢失的情况。
无论是至少一次还是最多一次，都不如精确一次来得有吸引力。大部分用户还是希望消息只会被交付一次，这样的话，消息既不会丢失，也不会被重复处理。
Kafka 分别通过 幂等性（Idempotence）和事务（Transaction）这两种机制实现了 精确一次（exactly once）语义。
------------------------------数据上游去重-------------------------------------
幂等性 Producer
幂等性最大的优势在于我们可以安全地重试任何幂等性操作，反正它们也不会破坏我们的系统状态。
在 Kafka 中，Producer 默认不是幂等性的，但我们可以创建幂等性 Producer。它其实是 0.11.0.0 版本引入的新功能。指定 Producer 幂等性的方法很简单，仅需要设置一个参数即可，即 props.put(“enable.idempotence”, ture)
，或 props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG， true)
。
enable.idempotence 被设置成 true 后，Producer 自动升级成幂等性 Producer，其他所有的代码逻辑都不需要改变。Kafka 自动帮你做消息的重复去重。
底层具体的原理很简单，就是经典的用空间去换时间
的优化思路，即在 Broker 端多保存一些字段。当 Producer 发送了具有相同字段值的消息后，Broker 能够自动知晓这些消息已经重复了，于是可以在后台默默地把它们“丢弃”掉。
但是，幂等性producer只能保证单分区上的幂等性，即一个幂等性Producer 能够保证某个主题的一个分区上不出现重复消息，它无法实现多个分区的幂等性。其次，它只能实现单会话上的幂等性，不能实现跨会话的幂等性。这里的会话，你可以理解为 Producer 进程的一次运行。当你重启了Producer 进程之后，这种幂等性保证就丧失了。
事务型producer（Transaction）
事务型 Producer 能够保证将消息原子性地写入到多个分区中。这批消息要么全部写入成功，要么全部失败。另外，事务型 Producer 也不惧进程的重启。Producer 重启回来后，Kafka 依然保证它们发送消息的精确一次处理。
设置事务型 Producer 的方法也很简单，满足两个要求即可：和幂等性 Producer 一样，开启 enable.idempotence =true。设置 Producer 端参数 transctional. id。最好为其设置一个有意义的名字。此外，你还需要在 Producer 代码中做一些调整，如这段代码所示：
producer.initTransactions();try {producer.beginTransaction();producer.send(record1);producer.send(record2);producer.commitTransaction();} catch (KafkaException e) {producer.abortTransaction();}
简单来说，幂等性 Producer 和事务型 Producer 都是Kafka 社区力图为 Kafka 实现精确一次处理语义所提供的工具，只是它们的作用范围是不同的。幂等性 Producer 只能保证单分区、单会话上的消息幂等性；而事务能够保证跨分区、跨会话间的幂等性。从交付语义上来看，自然是事务型Producer 能做的更多。不过，切记天下没有免费的午餐。比起幂等性 Producer，事务型 Producer 的性能要更差，在实际使用过程中，我们需要仔细评估引入事务的开销，切不可无脑地启用事务。
以上是kafka实现精确一次发送的方案，也就是生产者重试造成的消息重复问题,还有一种情况，就是如果消费者消费完数据，突然宕机了，没有提交位移，这样也会造成重复消费问题，那我们该怎么办呢？
-----------------------------消费者端实现幂等-------------------------------
消息队列即使做到了Exactly once级别，consumer也还是要做幂等。因为在consumer从消息队列取消息这里，如果consumer消费成功，但是ack失败，consumer还是会取到重复的消息，所以消息队列花大力气做成Exactly once并不能解决业务侧消息重复的问题。
解决方案
业务代码中实现
即手动判断幂
幂等实际上就两种方法:
(1)、将唯一键存入第三方介质，要操作数据的时候先判断第三方介质(数据库或者缓存)有没有这个唯一键。
(2)、将版本号(offset)存入到数据里面，然后再要操作数据的时候用这个版本号做乐观锁，当版本号大于原先的才能操作。
