14 幂等生产者和事务生产者

kafka消息交付可靠性保障和精确一次语义处理

消息交付可靠性保障，指的kafka对Producer和Consumer要处理的消息提供什么样的承诺。总共就三种：at most once 、at least once、axactly once
kafka默认提供的是 at least once。原因是只有Broker提交消息并且Producer收到Broker的应答才会认为该消息已经成功发送，如果应答的过程网络抖动了，则生产者没有收到应答只能选择重试。
kafka可以提供 exactly once，通过幂等生产者或者事务生产者实现。

幂等性

幂等性操作可以安全地重试而不会破坏系统状态。如果是非幂等性操作，还要担心多次执行对系统状态的影响。

幂等性Produder

开启：props.put(“enable.idempotence”, ture)
原理：空间换时间的思路。在Broker端多保留一些字段，在Producer发送了具有相同字段的消息后，将重复的消息“丢弃”。大致这么理解，原理还需要深究。
局限性：
1.只能保证单分区的幂等性，即只能保证某个主题的某个分区上不出现重复的消息。无法实现多个分区的幂等性。
其实这里指的应该是不能保证消息原子性写入到多个分区（一批消息要么全部写入成功，要么全部失败）？看了后面的评论感觉是的。
一个幂等的Producer，保证单分区的幂等性，Producer消息会发给主题的多个分区，每个分区都保证幂等性，实际上就是实现了多分区的幂等性。
2.不能实现跨会话的幂等性。会话可以理解为Producer的一次运行。
重启后producer进程的PID就变化了，broker就不认识了。想要broker能够认识，就需要做更多事情，也就是kafka事务做的事情。

事务Producer

数据库安全特性ACID，I指的是隔离性，即并发执行的食物彼此隔离互不影响。隔离级别中，read commited指的是读取数据库只能读取已提交的消息，写数据只能覆盖已提交的消息。

kafka提供事务的支持，主要是在read commited隔离级别。事务Producer提供了两个特性：
1.保证一批消息原子性写入多个分区，要么全部成功，要么全部失败。

producer.initTransactions();
try {
            producer.beginTransaction();
            producer.send(record1);
            producer.send(record2);
            producer.commitTransaction();
} catch (KafkaException e) {
            producer.abortTransaction();
}
1
2
3
4
5
6
7
8
9

record1和record2当作一个事务提交到kafka

2.Producer重启，kafka依然能保证它发送消息的精确一次处理。

使用
Producer端

• 开启 enable.idempotence = true
• 设置Producer参数transaction.id
• 在Producer中显式调用事务API
  Consumer端
• 设置参数isolation.level为read_committed。如果设置为read_uncommitted，则Consumer可以读取所有消息，包括事务成功和事务中指写入的消息（无论事务成功失败都会写入消息，kafka事务失败不会回滚，写入日志是append-only风格）。当然事务Consumer是能看到非事务Producer的所有消息的。

评论区精选

1.对kafka事务的其他描述：能够保证一条消息仅仅保存在kafka的某一分区上，不会出现在多个分区上。另外能保证多条消息原子性发送到多个分区。也就是只保证Producer到Kafka Broker的消息不重复不丢失。
2.如何保证消费者精确一次消费：kafka事务只保证Producer到Kafka Broker的消息不重复不丢失，Consumer端由于提交偏移量和消息处理的顺序有前有后，依然可能导致重复消费或者消息丢失，如果要实现消费者端精确一次消费，还需要额外的机制实现偏移量提交和消息消费的事务处理。

重复消费例子：Consumer端处理逻辑比较重超时没提交ACK（比如顺序是改库-远程调用-提交偏移量，远程调用超时了），但是处理逻辑已经执行了，下次重新消费还会消费到重复的数据，所以业务上要做幂等。

消息丢失例子：先提交偏移量在处理消息，处理消息过程发生异常。

3.事务Producer是怎么实现多分区以及多会话上的消息无重复（原理）？
主要机制是两阶段提交（2PC）。引入事务协调器帮助完成分布式事务。

4.不启用幂等也能保证同分区下无消息乱序的方法。比如消息发送失败重发，会导致在broker的消息顺序和producer发送消息的顺序不一样。max.in.flight.requests.per.connection = 1来实现。这样producer会等待之前请求的消息发送成功才会发送下一个（对吞吐量的影响？）

5.producer retry会保证消息发送到同一个分区，不然幂等性无法保障。

6.幂等kafka有局限性，说明kafka不能完全保证消费者重复消费，最好使用业务去重。即使consumer读到了事务消息，但还是可能由于rebalance等原因导致重复消费。

7.“那么你可能会问，如果我想实现多分区以及多会话上的消息无重复，应该怎么做呢？答案就是事务（transaction）或者依赖事务型 Producer。这也是幂等性 Producer 和事务型 Producer 的最大区别！”这句话的意思是说事务本身已经保证了事务内所有消息的幂等性了么？
答曰事务提供的一致性要高于幂等性

8.我理解幂等是保证消息不重复，事务是保证“批量消息”原子性写入不丢失。因为kafka本身已经保证当broker响应peoducer已提交后消息不丢失，如果我没有批量写入需求，是否就单独通过幂等保证精确一次呢
答曰依然不能保证多个分区同时写入消息的事务性