【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了:

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

相关推荐
码不停蹄的玄黓1 小时前
MySQL分布式ID冲突详解:场景、原因与解决方案
数据库·分布式·mysql·id冲突
王小王-1232 小时前
基于Hadoop的公共自行车数据分布式存储和计算平台的设计与实现
大数据·hive·hadoop·分布式·hadoop公共自行车·共享单车大数据分析·hadoop共享单车
要开心吖ZSH4 小时前
《Spring 中上下文传递的那些事儿》Part 4:分布式链路追踪 —— Sleuth + Zipkin 实践
java·分布式·spring
幼稚园的山代王5 小时前
RabbitMQ 4.1.1初体验
分布式·rabbitmq·ruby
百锦再5 小时前
RabbitMQ用法的6种核心模式全面解析
分布式·rabbitmq·路由·消息·通道·交换机·代理
一路向北North5 小时前
RabbitMQ简单消息监听和确认
分布式·rabbitmq·ruby
真实的菜5 小时前
Kafka生态整合深度解析:构建现代化数据架构的核心枢纽
架构·kafka·linq
一路向北North12 小时前
使用reactor-rabbitmq库监听Rabbitmq
分布式·rabbitmq·ruby
Amy1870211182317 小时前
赋能低压分布式光伏“四可”建设,筑牢电网安全新防线
分布式
June bug21 小时前
【软考中级·软件评测师】下午题·面向对象测试之架构考点全析:分层、分布式、微内核与事件驱动
经验分享·分布式·职场和发展·架构·学习方法·测试·软考