【Kafka】Kafka生产者开启幂等性后报错:Cluster authorization failed.

文章目录

背景

  1. 用户业务需求,需要开启生产者的幂等性,生产者加了配置:enable.idempotence = true
  2. 用户使用的集群开启了ACL认证:SASL_PLAINTEXT/SCRAM-SHA-512
  3. 用户生产消息时报错:org.apache.kafka.common.errors.ClusterAuthorizationException: Cluster authorization failed.

解决

服务端配置

查看Kafka源码,发现生产者这个配置(enable.idempotence)有一个说明:

When set to 'true', the producer will ensure that exactly one copy of each message is written in the stream. If 'false', producer retries due to broker failures, etc., may write duplicates of the retried message in the stream. Note that enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to 5, <code>retries</code> to be greater than 0 and <code>acks</code> must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a <code>ConfigException</code> will be thrown.

查看Kafka官网,对改配置也有相同的说明:

总结一下,服务端要支持生产幂等性的话,需要保证以下几个配置:

  • enable.idempotence = true
  • max.in.flight.requests.per.connection = 5
  • acks = all

以下是为什么需要这么配置的原因:

  1. max.in.flight.requests.per.connection:它用于设定在单个生产者-代理连接上可以同时进行的未确认的发送请求的最大数量。当此值设为1时,生产者将在收到上一个请求的响应后才会发送下一个请求。这确保了消息的发送顺序,但可能会限制吞吐量。当此值大于1时,生产者可以同时发送多个请求,这可能会提高吞吐量。然而,如果某个请求失败,那么该请求后的所有请求都可能会在其之前成功,这可能会导致消息的发送顺序被打乱。在启用幂等性的情况下,此值需要设为5或更小的值,以保证消息的顺序和幂等性。
  2. retries:这个配置决定了生产者在发送失败后重试的次数。如果这个值为0,那么在网络故障或者其他故障情况下,消息可能会丢失。为了保证消息的可靠性,这个值需要大于0。
  3. acks:这个配置决定了生产者在认为消息已经被成功发送之前需要等待多少个副本的确认。如果这个值为'all',那么生产者会等待所有的副本都确认后才认为消息已经被成功发送。这可以保证在副本失败的情况下,消息不会丢失。

这些配置的组合可以确保在各种故障情况下,消息的顺序、可靠性和一致性都能得到保证。

ACL增加授权

因为集群开启了ACL认证,所以还需要开启幂等写的权限,执行以下命令进行开启:

plain 复制代码
./kafka-acls.sh --bootstrap-server kafka-m2wi5kig-headless.kafka-pro.svc.xadd.staff.xdf.cn:29092 --command-config m2wi5kig.properties --add --allow-principal
 User:kafka-m2wi5kig.plain1 --topic 'cdata_flink_kafka_test' --producer --idempotent

--command-config 需要指定该集群的admin账号及密码,格式如下:

plain 复制代码
security.protocol = SASL_PLAINTEXT
sasl.mechanism = SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="xxxx" password="xxxx";

执行完之后,可以看到权限中已经包含IDEMPOTENT_WRITE了:

用户重试了,不在报错,问题解决。

相关推荐
涛哥开发笔记10 小时前
Kakfa核心概念和架构
kafka
深圳蔓延科技1 天前
Kafka的高性能之路
后端·kafka
努力的小郑2 天前
从一次分表实践谈起:我们真的需要复杂的分布式ID吗?
分布式·后端·面试
AAA修煤气灶刘哥2 天前
别让Redis「歪脖子」!一次搞定数据倾斜与请求倾斜的捉妖记
redis·分布式·后端
阿里云云原生2 天前
嘉银科技基于阿里云 Kafka Serverless 提升业务弹性能力,节省成本超过 20%
kafka·serverless
Aomnitrix3 天前
知识管理新范式——cpolar+Wiki.js打造企业级分布式知识库
开发语言·javascript·分布式
程序消消乐3 天前
Kafka 入门指南:从 0 到 1 构建你的 Kafka 知识基础入门体系
分布式·kafka
智能化咨询3 天前
Kafka架构:构建高吞吐量分布式消息系统的艺术——进阶优化与行业实践
分布式·架构·kafka
Chasing__Dreams3 天前
kafka--基础知识点--5.2--最多一次、至少一次、精确一次
分布式·kafka