一文搞懂Kafka中的listeners配置策略

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: 1. listeners中的plaintext controller external是什么意思?2. Kraft模式下controller和broker有何区别?3. 集群节点之间同步什么数据,通过哪个端口,是否可以自定义端口?4. 客户端通过哪个端口连接到kafka,通过9092连接的是什么,broker还是controller?5. 为controller配置了单独的端口有什么用?6. control.plane.listener.name与controller.listener.names有何区别?
  1. listeners中的plaintext controller external是什么意思?
  2. Kraft模式下controller和broker有何区别?
  3. 集群节点之间同步什么数据,通过哪个端口,是否可以自定义端口?
  4. 客户端通过哪个端口连接到kafka,通过9092连接的是什么,broker还是controller?
  5. 为controller配置了单独的端口有什么用?
  6. control.plane.listener.name与controller.listener.names有何区别?

为了保护Kafka集群安全,那么就要保证Kafka各节点之间的通信安全。每个Kafka节点必须指定一组Listener,用于接收来自客户端和其它Kafka节点的请求。为了对客户端进行身份验证,可以为每个Listener设置一种安全机制,以确保对集群内部或客户端之间的通信进行加密。

通过配置listeners,Kafka节点可以监听多个端口。这个属性可以接收以逗号分隔的Listener列表。必须为每个Kafka节点指定至少一个Listener。Listener的格式如下:

{LISTENER_NAME}://{hostname}:{port}

LISTENER_NAME通常是一个见名知意的名称,用于说明Listener的目的。例如,把接收客户端流量的Listener称为CLIENT:

listeners=CLIENT://localhost:9092

Listener的安全协议在单独的配置中指定:

listener.security.protocol.map

这个配置项的值是一个map集合,Listener与安全协议使用冒号分隔,元素之间使用逗号分隔。如此以来就为每个Listener指定了安全协议。例如,指定CLIENTListener将使用SSL,而BROKERListener将使用PLAINTEXT。

listener.security.protocol.map=CLIENT:SSL,BROKER:PLAINTEXT

安全协议有如下选项(不区分大小写):

  1. PLAINTEXT
  2. SSL
  3. SASL_PLAINTEXT
  4. SASL_SSL

我们先看PLAINTEXT,该协议不提供安全性,也不需要任何额外的配置。后续章节中再介绍如何配置其余的协议。

如果每个Listener使用单独的安全协议,也可以使用安全协议名称直接作为listeners中的Listener名称。基于上面的示例,我们可以像下面这样定义:

listeners=SSL://localhost:9092,PLAINTEXT://localhost:9093

但是,我们建议为Listener提供显式名称,因为这会让每个Listener的用途更清晰。

可以通过inter.broker.listener.name来配置Broker之间通信的Listener。Broker之间的通信主要是分区复制。如果没有指定,则Broker间Listener由security.inter.broker.protocol指定的安全协议确定,缺省为PLAINTEXT

在KRaft集群中,配置项process.roles用于指定节点的角色,允许指定的角色有brokercontroller,或者同时指定二者。配置项inter.broker.listener.name专门用于指定Broker之间的通信使用哪个Listener。另一方面,控制器必须使用单独的Listener,该Listener由controller.listener.names配置。并且与inter.broker.listener.name的值相同。

对于依赖Zookeeper的经典集群,可以通过control.plane.listener.name配置一个单独的Listener,用于传递从活动Controller节点Broker节点的元数据。这样做的好处是,可以使用一个单独的线程处理这部分通信,这使得应用程序流量不妨碍元数据更改的及时传递(例如分区leader和ISR更新)。请注意,如果未设置control.plane.listener.name,则使用与inter.broker.listener(译注:可以叫做数据平面Listener)相同的Listener。

controller接收来自其它controller节点broker节点的请求。由于这个原因,即使节点不是控制器角色(即它只是一个Broker),它仍然必须指定控制器Listener以及配置它所需的任何安全属性(译注:controller要知道集群中全部的节点信息,因此指定这个配置项,就可以把broker自身信息上报给controller)。例如,我们可能在独立Broker上使用以下配置:

process.roles=broker # 本节点是broker节点
listeners=BROKER://localhost:9092
inter.broker.listener.name=BROKER
controller.quorum.voters=0@localhost:9093 # 指定全部控制器节点
controller.listener.names=CONTROLLER # 指定控制器Listener
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL # 指定控制器Listener安全协议

在本例中,虽然配置了控制器Listener,但是它并未包含在listeners中,因为broker节点不需要开放控制器Listener。在这种情况下将使用controller.quorum.voters配置的端口。这是投票权配置项,它指定了所有控制器的列表。

对于同时启用broker和controller角色的KRaft集群节点,配置是类似的。唯一的区别是控制器Listener必须包含在listeners中:

process.roles=broker,controller
listeners=BROKER://localhost:9092,CONTROLLER://localhost:9093 # 此处需要同时指定代理Listener和控制器Listener
inter.broker.listener.name=BROKER
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL

controller.quorum.voters中指定的端口要与listeners列表中公开的控制器Listener之一完全匹配。投票者精确匹配一个公开的控制器Listener。例如,这里CONTROLLERListener绑定到端口9093。然后,由controller.quorum.voters指定的连接字符串也必须使用端口9093。

控制器将接收controller.listener.names指定的任意Listener上的请求。通常只有一个控制器Listener,但也可能有更多。例如,集群通过滚动更新将活动Listener从一个端口或安全协议更改为另一个端口或安全协议的方法(一次滚动公开新的Listener,一次滚动删除旧的Listener)。当指定了多个控制器Listener时,列表中的第一个Listener将用于发送请求。

在下一节中,将介绍如何在Listener上启用SSL以进行加密和身份验证。接下来的部分将介绍使用SASL的其他身份验证机制。

总结

Listener格式如下:

{LISTENER_NAME}://{hostname}:{port}

listeners配置项允许配置多个Listener:

listeners=CLIENT://localhost:9092,CONTROLLER://localhost:9093

同时需要通过listener.security.protocol.map为每个Listener指定安全协议。

在传统ZK集群上,使用control.plane.listener.name指定控制器Listener,而Kraft集群上则通过controller.listener.names指定控制器Listener。

翻译原文连接:https://kafka.apache.org/documentation/#listener_configuration

相关文章
|
1月前
|
消息中间件 监控 大数据
优化Apache Kafka性能:最佳实践与调优策略
【10月更文挑战第24天】作为一名已经对Apache Kafka有所了解并有实际使用经验的开发者,我深知在大数据处理和实时数据流传输中,Kafka的重要性不言而喻。然而,在面对日益增长的数据量和业务需求时,如何保证系统的高性能和稳定性成为了摆在我们面前的一个挑战。本文将从我的个人视角出发,分享一些关于如何通过合理的配置和调优来提高Kafka性能的经验和建议。
68 4
|
2月前
|
消息中间件 监控 Ubuntu
大数据-54 Kafka 安装配置 环境变量配置 启动服务 Ubuntu配置 ZooKeeper
大数据-54 Kafka 安装配置 环境变量配置 启动服务 Ubuntu配置 ZooKeeper
83 3
大数据-54 Kafka 安装配置 环境变量配置 启动服务 Ubuntu配置 ZooKeeper
|
28天前
|
消息中间件 存储 Prometheus
Kafka集群如何配置高可用性
Kafka集群如何配置高可用性
|
4月前
|
消息中间件 负载均衡 Kafka
Kafka分区分配策略大揭秘:RoundRobin、Range、Sticky,你真的了解它们吗?
【8月更文挑战第24天】Kafka是一款突出高吞吐量、可扩展性和数据持久性的分布式流处理平台。其核心特性之一是分区分配策略,对于实现系统的负载均衡和高可用性至关重要。Kafka支持三种主要的分区分配策略:RoundRobin(轮询)、Range(范围)和Sticky(粘性)。RoundRobin策略通过轮询方式均衡分配分区;Range策略根据主题分区数和消费者数量分配;而Sticky策略则在保持原有分配的基础上动态调整,以确保各消费者负载均衡。理解这些策略有助于优化Kafka性能并满足不同业务场景需求。
306 59
|
2月前
|
消息中间件 分布式计算 算法
大数据-67 Kafka 高级特性 分区 分配策略 Ranger、RoundRobin、Sticky、自定义分区器
大数据-67 Kafka 高级特性 分区 分配策略 Ranger、RoundRobin、Sticky、自定义分区器
51 3
|
2月前
|
消息中间件 分布式计算 Java
大数据-73 Kafka 高级特性 稳定性-事务 相关配置 事务操作Java 幂等性 仅一次发送
大数据-73 Kafka 高级特性 稳定性-事务 相关配置 事务操作Java 幂等性 仅一次发送
31 2
|
2月前
|
消息中间件 Java 大数据
大数据-56 Kafka SpringBoot与Kafka 基础简单配置和使用 Java代码 POM文件
大数据-56 Kafka SpringBoot与Kafka 基础简单配置和使用 Java代码 POM文件
70 2
|
2月前
|
消息中间件 NoSQL Kafka
大数据-116 - Flink DataStream Sink 原理、概念、常见Sink类型 配置与使用 附带案例1:消费Kafka写到Redis
大数据-116 - Flink DataStream Sink 原理、概念、常见Sink类型 配置与使用 附带案例1:消费Kafka写到Redis
151 0
|
4月前
|
消息中间件 Java 大数据
"深入理解Kafka单线程Consumer:核心参数配置、Java实现与实战指南"
【8月更文挑战第10天】在大数据领域,Apache Kafka以高吞吐和可扩展性成为主流数据流处理平台。Kafka的单线程Consumer因其实现简单且易于管理而在多种场景中受到欢迎。本文解析单线程Consumer的工作机制,强调其在错误处理和状态管理方面的优势,并通过详细参数说明及示例代码展示如何有效地使用KafkaConsumer类。了解这些内容将帮助开发者优化实时数据处理系统的性能与可靠性。
95 7
|
4月前
|
消息中间件 安全 Kafka
"深入实践Kafka多线程Consumer:案例分析、实现方式、优缺点及高效数据处理策略"
【8月更文挑战第10天】Apache Kafka是一款高性能的分布式流处理平台,以高吞吐量和可扩展性著称。为提升数据处理效率,常采用多线程消费Kafka数据。本文通过电商订单系统的案例,探讨了多线程Consumer的实现方法及其利弊,并提供示例代码。案例展示了如何通过并行处理加快订单数据的处理速度,确保数据正确性和顺序性的同时最大化资源利用。多线程Consumer有两种主要模式:每线程一个实例和单实例多worker线程。前者简单易行但资源消耗较大;后者虽能解耦消息获取与处理,却增加了系统复杂度。通过合理设计,多线程Consumer能够有效支持高并发数据处理需求。
176 4