多partition下无法保障消息的顺序性


 

由于问题比较宽泛,需要针对不同场景来分析,以下所有的分析都是基于同一个partition下的场景细化,多partition下无法保障消息的顺序性,但是碰到如下场景还是需要调整参数。

场景一:设置了retries>0,并且max.in.flight.requests.per.connection>1

先说明下这两个参数的含义:

retries

生产者从服务器收到的错误有可能是临时性的错误(比如分区找不到首领)。在这种情况下,retries 参数的值决定了生产者可以重发消息的次数,如果达到这个次数,生产者会放弃重试并返回错误。

默认情况下,生产者会在每次重试之间等待 100ms,不过可以通过 retry.backoff.ms 参数来改变这个时间间隔。建议在设置重试次数和重试时间间隔之前,先测试一下恢复一个崩溃节点需要多少时间(比如所有分区选举出首领需要多长时间),让总的重试时间比 Kafka 集群从崩溃中恢复的时间长,否则生产者会过早地放弃重试。不过有些错误不是临时性错误,没办法通过重试来解决(比如“消息太大”错误)。

max.in.flight.requests.per.connection

该参数指定了生产者在收到服务器响应之前可以发送多少个消息。它的值越高,就会占用越多的内存,不过也会提升吞吐量。把它设为 1 可以保证消息是按照发送的顺序写入服务器的,即使发生了重试。

这种场景下无法保障单一partition的有序,一般来说要保障消息的有序性,对于消息的可靠性也是有要求的,所以一般retries可以设置为大于0,但是max.in.flight.requests.per.connection设置为1即可,不过这样就有一个问题,导致了消息的吞吐量大大降低。

再发散一下,max.in.flight.requests.per.connection保障消息有序的逻辑源码时如何实现的呢?

在生产者消息发送线程Sender里面sendProducerData方法,里面有关于保障消息有序的一段逻辑如下:

		//如果需要保证消息的强顺序性,则缓存对应 topic 分区对象,防止同一时间往同一个 topic 分区发送多条处于未完成状态的消息
        if (guaranteeMessageOrder) {
            // 将每个batch的分区对象信息加入到mute集合,采取Set实现,重复的topicpartition信息不会被加入
            for (List<ProducerBatch> batchList : batches.values()) {
                for (ProducerBatch batch : batchList)
                    this.accumulator.mutePartition(batch.topicPartition);
            }
        }

实际上就是将本批次消息所在的分区信息添加到一个集合中,以保障每个topic下的该分区只有一个批次发送,如下:

 public void mutePartition(TopicPartition tp) {
        muted.add(tp);
    }

场景二:需要提升吞吐量max.in.flight.requests.per.connection设置大于1

此场景下业务要保障消息的吞吐量,那么max.in.flight.requests.per.connection必然就会选择更大的一个阈值,但是此场景还能保障消息有序性吗?

答案是肯定的,可以设置enable.idempotence=true,开启生产者的幂等生产,可以解决顺序性问题,并且允许max.in.flight.requests.per.connection设置大于1

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值