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

文章目录

背景
解决
- 服务端配置
- ACL增加授权

背景

用户业务需求，需要开启生产者的幂等性，生产者加了配置：enable.idempotence = true
用户使用的集群开启了ACL认证：SASL_PLAINTEXT/SCRAM-SHA-512
用户生产消息时报错：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

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

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

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