Apache Kafka(五)- Safe Kafka Producer

Kafka Safe Producer

在应用Kafka的场景中,需要考虑到在异常发生时(如网络异常),被发送的消息有可能会出现丢失、乱序、以及重复消息。

对于这些情况,我们可以创建一个“safe producer”,用于规避这些问题。下面我们会先介绍对于这几种情况的说明以及配置,最后给出一个配置示例。

 

1. acks 详述

之前我们介绍过 Kafka Producer 的 acks 有三种模式,下面我们进一步介绍一下这三种模式:

1.1.  acks = 0(no acks

使用acks=0 时,也就意味着:

  • 在发送一条message 后,不需要response
  • 如果broker 下线或是发生了故障,则我们不会知道,并且会丢失数据,因为broker不会返回任何response 给producers

acks=0 的工作方式如下图,不需要收到任何 ack:

 

一般使用 acks=0 的场景为:可以接受可能丢失数据。例如:

  • 指标信息收集
  • 日志收集(可接受偶尔丢失几条log数据)

 

1.2.  acks=1(leader acks

使用acks=1 时:

  • producer需要获取leader 的response,才能确认消息已被收到。但是replication是否收到则不会保证(会在后台执行replication)
  • 如果producer 没有收到ack,则可能会retry

acks=1 的工作方式如下图,Producer需要收到每条消息的ack:

 

  • 如果leader broker下线或是发生故障,但是replicas还没有复制发送的数据,则我们也会有数据丢失
  • 默认是这个模式

 

1.3.  acks=all(replicas acks

使用acks=all 时:

  • 需要Leader与Replicas的ack
  • 增加了latency与更高的“数据不丢失”安全性
  • 如果有足够的replicas,则不会有数据丢失

acks=all的一个工作方式如下,每个replica都需要回复ack,才能保证一个write的写入:

 

 

如果是需要完全不丢失数据,则这个设置是有必要考虑的。

在设置 acks=all(也就是replica acks)时,必须与另一个参数一起用,也就是:min.insync.replicas:

  • min.insync.replicas参数可以在broker level设置或是topic level设置(override)
  • min.insync.replicas=2表示的是:至少2个brokers是ISR(in-sync replicas)(包括leader),且必须响应表示它们有数据,否则就会返回报错。设置此参数为2也是最常见的配置。

假设设置参数replication.factor=3, min.insync=2, acks=all,则最多只能容许1一个broker异常,否则producer在发送数据时会收到报错。

假设有3个brokers,min.insync.replicas=2,若其中有两个broker异常,则Producer会收到“NOT_ENOUGH_REPLICAS”的异常。

 

2. Producer Retry

为了防止一些瞬时的错误(例如NotEnoughReplicasException)影响整个应用,一般我们需要处理一些异常,以避免数据丢失。在Producer中也有重试的配置,默认为0,可以手动调整它的值,最高可以到Integer.MAX_VALUE。

在重试时,默认情况下,会有可能造成消息发送时乱序。因为一般发送失败的消息会被re-queue,然后再次发送,所以会造成部分消息乱序。

此情况在key-based 序列消息中,尤为严重。因为所有具有相同key的messages会被送往同一个partition,而若是有消息被requeue,然后重传,则会打乱这个partition中的部分key顺序。

对于这种情况,我们可以设置参数max.in.flight.requests.per.connection控制:同一时刻,有多少个produce请求可以被并行发起:

  • 默认为5
  • 如果为了完全确保重试后的消息也能保持严格有序,则可以设置此参数为1(但是可能会影响throughput)

 不过在 Kafka >= 1.0.0中,对于此场景会有更好的解决方案,本文之后的部分会提及。

 

3. Idempotent Producer

在重传场景中,会遇到一个常见的问题是:由于网络的原因,Producer会在Kafka中引入重复的messages。

如下图所示:

 

一个正常的request请求为:

  1. Producer 发送消息到Kafka
  2. Kafka commit 这条消息
  3. Kafka发送ack回Producer

但是一个产生重复消息的请求过程为:

  1. Producer发送消息到Kafka
  2. Kafka commit 这条消息
  3. Kafka发送ack回Producer时,由于网络原因,ack未到达Producer端
  4. Producer过一段时间后开始重传消息
  5. Kafka commit这条重复的消息并返回ack给Producer

从Producer的角度看,它仅正常发送了一次消息,因为它只收到了一次 ack。从Kafka的角度看,它收到了两次消息,所以commit了两次。

在Kafka >= 0.11之后,可以定义一个“idempotent producer”,可以解决由网络问题造成的重复消息。如下图所示:

对于一个idempotent producer 来说,处理重复消息的请求过程为:

  1. Producer 发送一条消息
  2. Kafka收到消息并commit
  3. Kafka发送回Producer的ack由于网络问题未到达Producer
  4. Producer重试发送消息,在Producer>=0.11 的版本中,消息里会带上一个produce request id
  5. Kafka收到消息后,通过对比produce request id,可以辨别出这条消息是一条重复的消息,所以不会再次commit,并会再次发送一个ack

Idempotent producers可以很好的保证一个稳定,以及无重复数据的pipeline。

伴随Idempotent producers一起被设置的参数有:

  1. retries = Integer.MAX_VALUE (2^31-1 = 2147483647),也就是说基本会在出错时无限重传
  2. max.in.flight.requests=1 (Kafka >= 0.11 & < 1.1) ,也就是说在这些版本中,若是设置max.in.flight.requests > 1时仍会有可能产生乱序数据
  3. 或者 max.in.flight.requests=5 (Kafka >= 1.1 –> High Performance),也就是说在高于1.1版本的Kafka中,设置max.in.flight.requests=5也可以在保证不乱序的同时,保证并行的高性能

 

对于Idempotent Producer的配置,仅需配置类似以下参数即可:

properties.setProperty(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");

 

4. Safe Producer 配置总结

上面介绍了创建一个safe producer 所需的配置,下面我们总结一下在不同版本的Kafka中所需要做的配置:

Kafka < 0.11

  • ack=all (procuder level):确保在发送ack前,数据已经正常备份
  • min.insync.replicas=2 (broker/topic level):确保至少有两个in ISR 的brokers 有数据后再回送ack
  • retires=MAX_INT (producer level):确保在发生瞬时问题时,可以无限次重试
  • max.in.flight.requests.per.connection=1 (producer level):确保每次仅有一个请求发送,防止在重试时产生乱序数据

 

Kafka >= 0.11

  • enable.idempotence=true (producer level) + min.insync.replicas=2 (broker/topic level)
    • 隐含的配置为 acks=all, retries=MAX_INT, max.in.flight.requests.per.connection=5 (default)
    • 可以在保证消息顺序的同时,提高performance

这里必须要提到的是:运行一个“safe producer”可能会影响系统的throughput与latency,所以在应用到生产系统前,必须先做测试以判断影响。

 

5. safe producer 示例

我们按照之前的步骤启动一个由Java编写的Kafka Producer,并查看输出的配置,可以看到默认的部分参数为:

acks = 1

enable.idempotence = false

max.in.flight.requests.per.connection = 5

retries = 2147483647

 

现在我们显式地加上以下参数:

// create a safe Producer
properties.setProperty(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");
properties.setProperty(ProducerConfig.ACKS_CONFIG, "all");
properties.setProperty(ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION, "5");
properties.setProperty(ProducerConfig.RETRIES_CONFIG, Integer.toString(Integer.MAX_VALUE));

 

然后查看producer配置的部分输出为:

 

 

 

以上为创建一个safe producer所需的配置介绍以及示例,在实际生产环境中,务必要先测试safe producer 对应用吞吐以及延时的影响后,再斟酌是否有必要对参数做部分调整。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值