Kafka高级特性

用户88514866841
195 阅读20分钟

一、Kafka中的ISR（In-Sync Replicas）是什么？它在数据复制中扮演什么角色？

在 Kafka 中，ISR（In-Sync Replicas）是指与领导者副本（Leader Replica）保持同步的副本集。ISR 在 Kafka 的数据复制机制中扮演了至关重要的角色，确保数据的高可用性和可靠性。下面详细介绍 ISR 的概念及其在数据复制中的角色。

ISR（In-Sync Replicas）的概念

  • ISR：ISR 是一组副本，这些副本当前与领导者副本保持同步。换句话说，ISR 包含所有已成功获取并写入领导者副本上的最新消息的副本。
  • Leader Replica：每个分区都有一个领导者副本，负责处理所有的读写请求。
  • Follower Replicas：除了领导者副本外的其他副本，这些副本从领导者副本中复制数据以保持同步。

ISR 在数据复制中的角色

  1. 数据可靠性保证

    • 消息确认机制：生产者在发送消息时，可以指定不同的确认机制（acks 参数）。例如，acks=all 表示消息必须被写入所有 ISR 副本才算成功。这确保了数据在多个副本上持久化，提高了数据的可靠性。

  2. 故障恢复能力

    • 领导者故障切换：如果当前领导者副本发生故障，Kafka 会从 ISR 中选择一个新的领导者。由于 ISR 副本与领导者副本保持同步，因此可以快速切换，减少服务中断时间。

  3. 高可用性

    • 同步副本：通过确保 ISR 副本集中的每个副本都持有最新的消息，Kafka 提供了高可用性的数据存储。即使某些副本失败，ISR 中的其他副本仍然可以提供数据访问。

  4. 分区平衡和副本管理

    • 副本再平衡：当一个副本恢复或新的副本加入时，它需要从领导者副本中复制数据以赶上最新状态，随后加入 ISR 集。Kafka 自动管理这种副本再平衡过程，以维持 ISR 的完整性和同步性。

ISR 相关操作和配置

  1. 查看 ISR 状态

    • 使用 kafka-topics.sh 工具查看特定 Topic 的 ISR 状态：

      bin/kafka-topics.sh --describe --topic <topic-name> --bootstrap-server <broker-address>

  2. 调整副本同步相关配置

    • replica.lag.time.max.ms：配置副本滞后最大时间。如果一个副本滞后超过这个时间没有追上领导者，它将被移出 ISR。
    • min.insync.replicas：配置最小的同步副本数量。此参数用于配置生产者发送消息时，要求最少有多少个副本必须确认消息写入成功。

示例配置

假设你想配置一个 Kafka 集群，使其在生产消息时至少有两个副本必须同步成功，你可以在 server.properties 文件中进行如下配置：

# 配置 ISR 滞后时间
replica.lag.time.max.ms=10000

# 配置最小 ISR 数量
min.insync.replicas=2

具体操作示例

查看 ISR 状态

  1. 查看特定 Topic 的详细信息：

    bin/kafka-topics.sh --describe --topic my-topic --bootstrap-server localhost:9092

    该命令的输出将包括每个分区的 ISR 列表，如下所示：

    Topic: my-topic PartitionCount: 3 ReplicationFactor: 2 Configs: 
Topic: my-topic Partition: 0 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: my-topic Partition: 1 Leader: 2 Replicas: 2,3 Isr: 2,3
Topic: my-topic Partition: 2 Leader: 3 Replicas: 3,1 Isr: 3,1

调整副本同步相关配置

在 Kafka 的 server.properties 文件中，可以设置如下参数：

# 设置副本滞后最大时间
replica.lag.time.max.ms=10000

# 设置最小的同步副本数量
min.insync.replicas=2

然后重启 Kafka Broker 以应用这些配置。

总结

ISR（In-Sync Replicas）在 Kafka 的数据复制机制中扮演了关键角色，确保数据的高可用性和可靠性。通过维护与领导者副本同步的副本集，ISR 使 Kafka 能够在副本故障时快速恢复，并确保消息的可靠持久化。了解和管理 ISR 是维护 Kafka 集群稳定性和性能的关键。

二、Kafka如何保证数据的一致性和可靠性？

Kafka 通过多种机制来确保数据的一致性和可靠性。以下是 Kafka 如何实现这些目标的详细说明：

数据一致性

  1. 副本同步机制（ISR）

    • Kafka 使用 ISR（In-Sync Replicas）来保证数据的一致性。ISR 是一个包含所有与领导者副本保持同步的副本集合。当消息被写入领导者副本时，Kafka 会将消息复制到 ISR 中的所有副本，确保数据的一致性。

  2. 确认机制（Acks）

    • 生产者在发送消息时可以指定 acks 参数：

      • acks=0：生产者不等待任何确认，即火即发，不保证消息的持久化。
      • acks=1：生产者等待领导者副本写入成功后确认，不保证数据已被复制到 ISR。
      • acks=all：生产者等待所有 ISR 副本都写入成功后确认，确保消息被复制到所有同步副本。

  3. 最小同步副本（min.insync.replicas）

    • 配置项 min.insync.replicas 指定了最小的同步副本数量，生产者在使用 acks=all 时，必须有至少 min.insync.replicas 个副本成功写入消息，才能确认成功。这进一步确保了数据的一致性。

数据可靠性

  1. 数据复制

    • Kafka 通过分区的多副本机制来提高数据的可靠性。每个分区有一个领导者副本和若干个跟随者副本，领导者副本负责处理读写请求，跟随者副本从领导者副本同步数据。当领导者副本发生故障时，Kafka 会从 ISR 中选取一个新的领导者，确保数据的可用性。

  2. 日志段和索引

    • Kafka 将数据写入日志段（Log Segment），每个日志段都有一个对应的索引文件，用于快速定位消息。日志段和索引文件定期进行滚动和清理，确保数据可靠地存储在磁盘上。

  3. 副本再平衡

    • 当一个副本恢复或新的副本加入时，它需要从领导者副本中复制数据以赶上最新状态。Kafka 自动管理这种副本再平衡过程，以维持 ISR 的完整性和同步性。

  4. 持久化和故障恢复

    • Kafka 使用顺序写入的方式将数据写入磁盘日志文件，这种方式不仅高效而且可靠。即使在服务器宕机的情况下，Kafka 也能通过读取日志文件进行故障恢复。

  5. 数据保留策略

    • Kafka 提供了多种数据保留策略，确保数据在指定的时间或大小内保留：

      • 时间保留：通过 log.retention.hours 配置，Kafka 可以保留一定时间内的数据。
      • 大小保留：通过 log.retention.bytes 配置，Kafka 可以保留一定大小的数据。
      • 日志段删除：通过 log.segment.bytes 和 log.segment.ms 配置，Kafka 可以定期滚动和删除旧的日志段。

配置示例

假设你想配置 Kafka 以确保高一致性和可靠性，可以在 server.properties 文件中进行如下配置：

# 副本滞后最大时间
replica.lag.time.max.ms=10000

# 最小的同步副本数量
min.insync.replicas=2

# 数据保留时间
log.retention.hours=168

# 数据保留大小
log.retention.bytes=1073741824

# 日志段大小
log.segment.bytes=1073741824

# 日志段滚动时间
log.segment.ms=604800000

故障恢复操作

  1. ISR 监控

    • 使用 Kafka 提供的工具查看 ISR 状态，确保所有副本与领导者副本保持同步：

      bin/kafka-topics.sh --describe --topic <topic-name> --bootstrap-server <broker-address>

  2. 副本再平衡

    • 在添加新节点或修复故障节点后，Kafka 会自动进行副本再平衡，确保所有副本都加入 ISR 并保持同步。

  3. 日志段修复

    • 如果遇到磁盘故障或日志损坏，Kafka 可以通过读取和恢复日志段来恢复数据，确保消息的可靠性。

总结

Kafka 通过 ISR、确认机制（acks）、最小同步副本（min.insync.replicas）、数据复制、日志段和索引、副本再平衡、持久化和故障恢复，以及数据保留策略等多种机制，确保了数据的一致性和可靠性。合理配置和监控这些机制，有助于维护 Kafka 集群的高可用性和数据可靠性。

三、Kafka中的Leader和Follower分别是什么？它们如何协同工作？

在Apache Kafka中，集群中的每个主题（Topic）被分成若干个分区（Partition），每个分区都有一个Leader和若干个Follower。Leader和Follower在Kafka中的角色和工作机制如下：

Leader

  1. 定义：Leader是负责处理所有读写请求的主要节点。每个分区都有一个Leader，由Kafka集群中的一个Broker（代理）扮演。

  2. 职责：

    • 处理客户端请求：Leader节点负责处理来自生产者（Producer）的写请求和消费者（Consumer）的读请求。
    • 维护数据一致性：Leader会确保数据在被写入后立即同步给所有Follower，以确保数据的一致性和可靠性。

Follower

  1. 定义：Follower是负责复制Leader数据的从节点。每个分区可以有多个Follower，它们都跟随Leader的数据更新。

  2. 职责：

    • 数据同步：Follower不断从Leader那里拉取最新的数据，确保自己的数据副本与Leader一致。
    • 故障转移（Failover） ：在Leader发生故障时，一个Follower可以被选举为新的Leader，以保持系统的高可用性。

协同工作机制

  1. 写入数据：当生产者将数据写入Kafka时，它首先发送请求到该分区的Leader。Leader接收数据后，立即将数据写入本地日志，并向所有Follower发送复制请求。
  2. 数据复制：Follower接收到Leader的复制请求后，将数据写入自己的本地日志，并向Leader确认接收。Leader收到大多数Follower的确认后，认为该条数据已经成功复制，可以对外宣告写入成功。
  3. 读取数据：消费者在读取数据时，会直接从分区的Leader获取数据。Leader保证提供最新且完整的数据。
  4. Leader选举：如果Leader节点发生故障，Kafka的ZooKeeper组件会触发Leader选举算法，从剩余的Follower中选出一个新的Leader，以继续处理客户端请求和数据复制。

示例

假设我们有一个包含3个分区的主题，每个分区有一个Leader和两个Follower。如下图所示：

Partition 0: Leader (Broker 1), Follower (Broker 2), Follower (Broker 3)
Partition 1: Leader (Broker 2), Follower (Broker 1), Follower (Broker 3)
Partition 2: Leader (Broker 3), Follower (Broker 1), Follower (Broker 2)

在这种配置下，当生产者写入数据到Partition 0时：

  1. 数据首先发送到Broker 1（Partition 0的Leader）。
  2. Broker 1将数据写入本地，并将数据发送给Broker 2和Broker 3（Follower）。
  3. Broker 2和Broker 3收到数据后写入本地，并向Broker 1确认。
  4. 当Broker 1收到大多数Follower（在这个例子中是两个）的确认后，通知生产者写入成功。

如果Broker 1发生故障，ZooKeeper会检测到这个情况并选举Broker 2或Broker 3作为新的Leader，从而保证系统的高可用性。

总结

Kafka通过Leader和Follower的协同工作机制，实现了高吞吐量、低延迟的数据传输和存储，同时确保了数据的一致性和高可用性。这种设计使得Kafka在分布式系统中能够稳定可靠地运行。

四、Kafka中的事务性消息是如何实现的？

Kafka中的事务性消息（Transactional Messages）允许生产者在多个分区上原子地写入一组消息，以确保数据的一致性。事务性消息主要用于确保跨分区的操作要么全部成功，要么全部失败，从而避免数据的不一致性。下面是Kafka中实现事务性消息的机制：

关键概念

  1. 事务生产者（Transactional Producer） ：生产者以事务模式发布消息，确保一组消息在多个分区上原子性写入。
  2. 事务协调者（Transaction Coordinator） ：一个专门的组件，负责管理事务的生命周期，包括启动、提交和中止事务。
  3. 事务ID（Transaction ID） ：唯一标识每个事务生产者的标识符，用于跟踪事务的状态。

实现机制

  1. 初始化：

    • 配置事务ID：生产者在初始化时需要配置一个唯一的事务ID。
    • 获取协调者：生产者通过事务ID找到对应的事务协调者（Transaction Coordinator）。

  2. 开始事务：

    • 初始化事务：生产者调用initTransactions方法来初始化事务环境。
    • 开始事务：生产者调用beginTransaction方法来开始一个新事务。

  3. 发送消息：

    • 发送消息到分区：生产者在事务中发送消息，消息会带有事务标识。
    • 记录消息：每条消息都会被写入对应的分区，并记录到事务日志中。

  4. 提交或中止事务：

    • 提交事务：生产者调用commitTransaction方法来提交事务，事务协调者将确认所有消息已成功写入。

      • 两阶段提交：事务协调者使用两阶段提交协议（2PC）来保证所有分区的消息一致性。
      • 预提交：事务协调者先向所有参与的分区发送预提交请求。
      • 确认提交：如果所有分区都返回成功，事务协调者发送提交请求，完成事务。

    • 中止事务：如果事务需要中止，生产者调用abortTransaction方法，事务协调者将通知所有分区丢弃未提交的消息。

  5. 事务日志：

    • 记录事务状态：事务协调者会在内部主题__transaction_state中记录每个事务的状态（如开始、提交或中止）。
    • 故障恢复：如果生产者或协调者发生故障，可以通过事务日志恢复事务状态，确保数据一致性。

示例代码

以下是一个使用Kafka事务性消息的示例代码：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("transactional.id", "my-transactional-id");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

producer.initTransactions();

try {
    producer.beginTransaction();
    
    // Send messages as part of the transaction
    producer.send(new ProducerRecord<>("my-topic", "key1", "value1"));
    producer.send(new ProducerRecord<>("my-topic", "key2", "value2"));
    
    producer.commitTransaction();
} catch (ProducerFencedException | OutOfOrderSequenceException | AuthorizationException e) {
    // Fatal errors, the producer should not be used anymore
    producer.close();
} catch (KafkaException e) {
    // Abort the transaction and try again
    producer.abortTransaction();
}
producer.close();

优缺点

优点：

  1. 数据一致性：确保在多个分区上的消息写入操作具有原子性，防止数据不一致。
  2. 简化编程模型：开发者无需手动管理跨分区的一致性，减少复杂性。

缺点：

  1. 性能开销：事务性消息引入了额外的协调和日志记录，可能会影响性能。
  2. 复杂性：事务性消息机制增加了系统的复杂性，特别是在故障恢复和协调方面。

通过事务性消息机制，Kafka能够在分布式环境中提供强一致性的消息传递服务，适用于金融交易、订单处理等需要高一致性保证的场景。

五、Kafka的幂等生产者（Idempotent Producer）是什么？它如何防止消息重复？

Kafka的幂等生产者（Idempotent Producer）是一种确保消息在Kafka集群中精确一次（exactly-once）投递的机制。这种机制能够防止由于重试或网络问题导致的消息重复，从而保证数据的一致性。幂等生产者通过以下几种方式实现防止消息重复：

关键概念

  1. 幂等性（Idempotency） ：确保相同的请求被执行多次，结果依然是一样的。
  2. Producer ID（PID） ：每个生产者实例会被分配一个唯一的生产者ID。
  3. Sequence Number：每条消息在其分区内都有一个唯一的序列号，生产者为每个分区维护一个单调递增的序列号。

实现机制

  1. 初始化幂等生产者：

    • 在生产者配置中启用幂等性：设置enable.idempotence属性为true。
    • 生产者启动时，会向Kafka集群请求分配一个唯一的Producer ID（PID）。

  2. 发送消息：

    • 维护序列号：生产者为每个分区维护一个序列号，每发送一条消息，序列号递增。
    • 附加序列号：每条消息都会附带其分区的序列号和生产者ID。

  3. 去重检查：

    • Broker端去重：Broker端会为每个分区维护一个最后接收到的序列号，当收到新消息时，会检查其序列号是否大于上次接收的序列号。
    • 重复消息丢弃：如果序列号小于或等于上次接收的序列号，Broker会识别为重复消息，并丢弃该消息。

  4. 故障处理：

    • 重试机制：当消息发送失败时，生产者会根据配置自动重试。
    • 确保顺序：重试的消息仍然会携带原始的序列号，Broker会继续进行去重检查，确保消息不会重复投递。

示例代码

以下是一个使用Kafka幂等生产者的示例代码：

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all");
props.put("retries", Integer.MAX_VALUE);
props.put("enable.idempotence", "true");

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

for (int i = 0; i < 100; i++) {
    producer.send(new ProducerRecord<>("my-topic", Integer.toString(i), Integer.toString(i)),
                  (metadata, exception) -> {
                      if (exception != null) {
                          exception.printStackTrace();
                      } else {
                          System.out.printf("Sent message with key %s to partition %d with offset %d%n",
                                            Integer.toString(i), metadata.partition(), metadata.offset());
                      }
                  });
}

producer.close();

优缺点

优点：

  1. 防止消息重复：通过序列号和去重检查，确保消息不会被重复投递。
  2. 简化开发：开发者无需在应用层处理消息重复问题，降低了代码复杂性。

缺点：

  1. 性能开销：启用幂等性会增加额外的元数据开销，可能会影响生产者的吞吐量。
  2. 依赖Kafka版本：幂等生产者特性需要Kafka 0.11.0或更高版本的支持。

适用场景

幂等生产者适用于需要严格确保消息唯一性和顺序性的场景，例如：

  • 金融交易系统
  • 订单处理系统
  • 日志和监控系统

通过幂等生产者，Kafka能够在高吞吐量、低延迟的前提下提供精确一次的消息传递保证，适用于要求高数据一致性的应用场景。

六、Kafka中的ACL（Access Control Lists）是什么？它如何控制访问权限？

在Apache Kafka中，ACL（Access Control Lists，访问控制列表）是一种用于控制和管理对Kafka集群中资源访问权限的机制。ACL允许管理员指定哪些用户或应用程序可以访问特定的Kafka资源（如主题、消费者组等），以及它们可以执行的操作（如读、写、管理等）。通过ACL，Kafka可以提供更细粒度的安全控制，以保护数据的安全性和隐私。

关键概念

  1. 资源类型：Kafka中的资源类型包括主题（Topic）、消费者组（Consumer Group）、集群（Cluster）等。
  2. 操作类型：可以对资源执行的操作类型，包括读（Read）、写（Write）、创建（Create）、删除（Delete）、描述（Describe）和管理（Alter）。
  3. 主体（Principal） ：指进行操作的实体，可以是用户、应用程序或服务账户。
  4. 权限类型：包括允许（Allow）和拒绝（Deny）。

实现机制

  1. 定义ACL：管理员通过Kafka命令行工具或API定义ACL规则，这些规则指定了特定主体对特定资源的访问权限。
  2. 存储ACL：Kafka将ACL规则存储在其内部主题（如__acl）中，这些规则会被集群的所有Broker共享。
  3. 访问控制检查：当主体尝试对某个资源执行操作时，Kafka会根据存储的ACL规则检查是否允许该操作。如果有明确的允许规则，则允许操作；如果有拒绝规则或没有明确的允许规则，则拒绝操作。

使用示例

以下是使用Kafka命令行工具创建和管理ACL的示例：

创建ACL

创建一个ACL规则，允许用户User:Alice读取主题my-topic：

kafka-acls --bootstrap-server localhost:9092 --add --allow-principal User:Alice --operation Read --topic my-topic

列出ACL

列出所有ACL规则：

kafka-acls --bootstrap-server localhost:9092 --list

列出特定主题my-topic的ACL规则：

kafka-acls --bootstrap-server localhost:9092 --list --topic my-topic

删除ACL

删除一个ACL规则，撤销用户User:Alice读取主题my-topic的权限：

kafka-acls --bootstrap-server localhost:9092 --remove --allow-principal User:Alice --operation Read --topic my-topic

优缺点

优点：

  1. 细粒度控制：可以精确控制每个用户或应用程序对不同资源的访问权限。
  2. 增强安全性：通过限制未授权访问，保护敏感数据和防止恶意操作。
  3. 灵活配置：支持多种操作类型和资源类型，可以满足不同的安全需求。

缺点：

  1. 配置复杂：在大型集群中，配置和管理大量ACL规则可能会变得复杂。
  2. 性能影响：ACL检查可能会增加一些性能开销，尤其是在高并发访问的情况下。

适用场景

ACL适用于需要严格访问控制和数据保护的场景，例如：

  • 多租户环境：不同的团队或应用程序共享同一个Kafka集群，需要隔离访问权限。
  • 金融和医疗等高安全性行业：需要确保敏感数据仅被授权用户访问。
  • 数据隐私和合规性要求：满足法规要求，确保数据访问受控。

通过ACL，Kafka可以为其资源提供强有力的访问控制机制，确保数据安全和系统稳定。

七、Kafka如何支持消息的安全传输？包括哪些加密和认证机制？

Apache Kafka支持消息的安全传输，通过一系列的加密和认证机制来确保数据在传输过程中不被窃听、篡改和伪造。以下是Kafka提供的主要安全特性：

加密机制

  1. 传输层加密（TLS/SSL） ：

    • Kafka支持使用TLS/SSL加密来保护生产者、消费者、Broker和ZooKeeper之间的通信。
    • TLS/SSL可以确保数据在网络传输过程中不会被窃听或篡改。

配置示例

在生产者和消费者中配置SSL：

security.protocol=SSL
ssl.keystore.location=/path/to/keystore.jks
ssl.keystore.password=keystore-password
ssl.key.password=key-password
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=truststore-password

在Broker中配置SSL：

listeners=SSL://broker1:9093
ssl.keystore.location=/path/to/keystore.jks
ssl.keystore.password=keystore-password
ssl.key.password=key-password
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=truststore-password

认证机制

  1. SSL 客户端认证：

    • SSL不仅可以加密数据，还可以用于认证客户端。客户端和服务器通过互相验证证书来进行双向认证。

  2. SASL（Simple Authentication and Security Layer） ：

    • Kafka支持多种SASL机制，包括PLAIN、SCRAM、GSSAPI（Kerberos）和OAUTHBEARER。
    • SASL机制允许使用多种不同的身份验证方式，如用户名/密码、Kerberos票证等。

配置示例

使用SASL/PLAIN进行认证： 在Broker中配置SASL/PLAIN：

listeners=SASL_PLAINTEXT://broker1:9092
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN
listener.name.sasl_plaintext.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="admin" \
    password="admin-secret";

在生产者和消费者中配置SASL/PLAIN：

security.protocol=SASL_PLAINTEXT
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="user" \
    password="user-secret";

授权机制

  1. ACL（访问控制列表） ：

    • Kafka使用ACL来控制用户或应用程序对特定资源（如主题、消费者组、集群等）的访问权限。
    • ACL规则可以允许或拒绝用户对资源执行特定操作，如读、写、创建、删除、描述和管理。

ACL配置示例

添加ACL规则，允许用户User:Alice读取主题my-topic：

kafka-acls --bootstrap-server localhost:9092 --add --allow-principal User:Alice --operation Read --topic my-topic

安全配置示例总结

配置SSL/TLS

生产者/消费者配置：

security.protocol=SSL
ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks
ssl.truststore.password=test1234
ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234

Broker配置：

listeners=SSL://broker:9093
ssl.keystore.location=/etc/kafka/secrets/kafka.server.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=/etc/kafka/secrets/kafka.server.truststore.jks
ssl.truststore.password=test1234
ssl.client.auth=required

配置SASL/PLAIN

生产者/消费者配置：

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="alice" \
    password="alice-secret";

Broker配置：

listeners=SASL_SSL://broker:9093
sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="admin" \
    password="admin-secret";

小结

通过结合TLS/SSL加密、SASL认证和ACL授权机制，Kafka能够提供全面的安全保护措施，确保消息在传输过程中的保密性和完整性，并有效控制对Kafka资源的访问权限。这些安全特性使Kafka在需要高安全性和数据保护的应用场景中非常适用。

avatar
文章
阅读
粉丝