幂等性与事务性Producer区别(Kafka)

Posted 2021-05-02 大数据摘文

Kafka消息交付可靠性保障以及精准处理一次语义的实现

所谓消息交付可靠性保障，是指Kafka对Producer和Consumer要处理的消息提供什么样的承诺。

 最多一次（at most once）:

       消息可能会丢失，但绝不会被重复发送。

至少一次（at least once）:

      消息不会丢失，但可能会被重复发送。

精准一次（exactly once）:

      消息不会丢失，但也不会被重复发送。

Kafka默认提供的交付可靠性保障是第二种,即至少一次。消息已提交，即只有Broker成功提交消息且Producer接到Broker的应答才会认为该消息发送成功。

不过倘若消息成功提交，但Broker的应答没有成功发送回Producer端，那么Producer就无法确定消息是否真的提交成功了。因此，它只能选择重试，也就是再次发送相同的消息。这就是Kafka默认提供至少一次可靠性保障的原因，不过这会导致消息重复发送。

Kafka 也可以提供最多一次交付保障，只需要将Producer禁止重试。这样，消息要么成功，要么失败，但绝不会重复发送。通常不会希望出现消息丢失的情况，但有一些场景偶发的消息丢失其实是被允许的，相反，消息重复是绝对要避免的，此时，使用最多一次的交付保障就是最恰当的。

无论是至少一次还是最多一次，都不如精准一次有吸引力。即使Producer端重复发送了相同的消息，Broker端也能做到自动去重，在下游Consumer看来，消息依然只有一条。

Kafka幂等性和事务

No.1

什么是幂等性

计算机领域 幂等含义

  

最大优势在于我们可以安全得重试任何幂等性操作，反正它们也不会破坏我们得系统状态。

 

幂等性Producer

默认不是幂等的  是0.11.0.0版本引入的，在此之前，Kafka向分区发送数据时，可能会出现同一条消息被发送了多次，导致消息重复的情况。 在0.11后，指定Producer幂等性的方法很简单，仅需要设置一个参数即可，即

props.put("enable.idempotence",true)

Producer自动升级成幂等性的Producer,其他所有代码逻辑都不需要改变。Kafka自动帮你做消息去重的工作。底层原理，就是空间换时间，即在Broker端多保存一些字段，当Producer发送了具有相同的字段值的消息后，Broker能够自动知晓这些消息已经重复了，于是可以在后台默默把它们丢掉。

 适用范围

 （1）只能保证单分区上的幂等性，无法实现多个分区的幂等性；

（2）只能实现单会话上的幂等性，不能实现跨会话的幂等性，可以理解为Producer进程的一次运行，重启之后，幂等性消失。

如果想实现多分区及多会话上的消息无重复，需要依赖事务型Producer,也就是幂等性Producer和事务型Producer。

 

No.2

事务

  ACID  ：原子性、 一致性 、隔离性、 持久性

隔离性表明并发执行的事务彼此相互隔离，互不影响。Kafka自0.11版本 也开始提供了对事务的支持，目前主要实在Read committed隔离级别上做事情。能保证多条消息原子性地写入到目标分区，同时也能保证Consumer只能看到事务成功提交地消息。

事务型Producer

事务型Producer能够保证将消息原子性地写入到多个分区，这批消息要么全部写入成功，要么全部失败。另外，事务型Proudcer也不害怕进程重启，重启之后Kafka依然保证发送消息地精准一次处理。设置事务型Producer地方法 需满足两个要求：

  （1） enable.idempotence=true

  （2）设置Producer端参数transctional.id

代码实例

producer.initTransactions();try { producer.beginTransaction(); producer.send(record1); producer.send(record2);      producer.commitTransaction();} catch (KafkaException e) {      producer.abortTransaction();}

在Consumer端，读取事务型Producer发送地消息也需要一些变更，设置isolation.level为read_commited 表明Consumer只会读取事务型Producer成功提交事务写入地消息。